How Important Is It To Have Right Product Vision To Build A Right Product?

I was new to the team, and I was fresh in my role as a product owner, the team was working on two features for our very priority customer.
The team did not have any product owner or product manager before I arrived, I spoke to each team member to understand what they are working on and the features they are building on.

One product feature caught my attention, and this was because every member working in that feature gave me a different vision about the product feature. I could sense something is not right about product planning.

But as I was new, I was clueless about what was WRONG and at which stage. The feature was already in the development phase, which meant I barely had any time to CORRECT Things.

I was well aware firsthand just how challenging it could be to handle things and mainly THE TEAM.

So, here I what I did to handled the situation.

I gathered all the documents available for the feature, studied and jotted down what was the possible reason for the unclear state of the feature

• There were no proper documentation on Feature mission, vision or Value.
• Half baked analysis to derive the solution for feature implementation
• No roadmap defined

It was not Planned at all, and it was time to inform the stakeholders that we were not building RIGHT, and we should STOP right there.

I spoke to the team first, explained what I found, and proved that we are not building the RIGHT. I talked to stakeholders and management.

I got to know that the feature we were talking about was an exciting add-on feature, which was supposed to be delivered to customer a year before when they bought our baseline product, but this was never given to the customer became our lability. Management had not informed the customer about the background work the team was doing to clear this year-old lability; basically, the management didn’t want to remind the customer about this missing feature until it was ready.

So here we were safe from the customer communication perspective. Hence I delayed the delivery by two sprints and added this feature in the upcoming release. And then I started working on the feature as Fresh Requirement.

Here are the steps I followed:

1. Worked on the three essential pillars of a product, Vision, Mission and Value, documented and made sure the team has a clear vision about what they are supposed to do in the upcoming release.

Vision is all about the future you want to build.

Mission is the “why” — the purpose behind the product, Why the feature is needed for our customer.

Value: The outcome of your product should bring Value to your customer.

2. Research and analysis, I analyzed the solution defined before and found lots of gaps, “Thank God we didn’t build the product on an incomplete analysis”. I rectified all the gap and documented every single analysis outcome.

3. Based on the analysis, I did the solutioning, the solution changed completely, which meant the development work was on no use.

4. Once the solution was finalized, I made sure, this time we followed the right way and approval process,

my next work was to plan the delivery of the feature.

5. I did multiple grooming session with the team, to make sure all are clear about the “WHAT” and “WHY”

6. Once the team confirmed their understanding, in the backlog refinement, I made sure to find out if anything which was already done can be reused for the new solution, Good News!! We could find a few parts of the code which we could reuse.

7. We also discussed and figured out within our scrum, the HOW part and the critical QUALITY VALIDATION, Team and I did a rough estimation during the refinement meeting.

8. Now that I had clarity on what could be the possible timeline to deliver this feature.

9. Keep other priorities in mind, along with this feature, I came up with a feature delivery timeline, which was agreed by the tribe management.

10. Before the release started, we were all set with the right information, the right plan and the right way to build the right.

So what I learnt from this event was,

It’s never too late — never too late to start over, never too late to correct our mistakes. And if we do not, we will end up in more significant RISK.

Things to remember:

• Firstly you should be good in communication and building relationships with the team to talk and bring out lots of untold information.
• Raise early risk.
• Document Everything.
• See the invisible and do a proper analysis before defining the solution.
• Keep your team always align with what why and how.
• Do not compromise on the Quality of the product just for the sake of meeting some deadline.

I am sure those reading this blog might have other better ways to handle such situations about a product you would have worked on.

Please feel free to comment and let me know your way of handling a wrong product vision.