For every feature you decide to build and launch, you need answers to three critical questions:
1. Why are we building this
2. What are we exactly building
3. How will we build this given our strengths and constraints
Why are we building this
Who owns the answer: Product Manager.
What should the answer include:
1. Define why are you doing whatever you’re planning to do. Talk about the business rationale or the goal for prioritising this feature (and not others)
2. Include all the data and analysis that you used to prioritise the feature.
3. Be sure not to include the problem or the solution at this stage
For example:
We observed a 15% decrease in signups over the last three months. As part of this project, we will be improving the sign-up flow. We project that this will lead to an increase in signups by at least 7%.
Why is this answer important:
This answer is extremely critical to create transparency and get buy-in from stakeholders on the business rationale and the goal.
Sharing this information is the most effective tactic to get every one on the same page.
What are we exactly building
Who owns the answer: Primarily, the product manager answers this question. However, great product managers involve engineers early on to get their input.
What should the answer include:
1. Define the problem you are solving
2. Define the solution, on a high level, to the problem
For example:
Reduce the signup completion time by allowing users to complete signup without phone number verification.
Why is this answer important:
The answer to this question forms the basis of the agreement between the product manager and engineers. Both parties agree on the problem they’re solving and the high level solution they’re creating.
This answer is also the main input for answering the next question.
How will we build this given our strengths and constraints
Who owns the answer: Engineers
What should the answer include:
At this stage, the engineers create the highest level of details to define the solution.
Why is this answer important:
1. The details help engineers and product managers uncover any missed use cases or potential limitations.
2. It helps engineers validate assumptions, if any.
3. It helps the team to validate if the accuracy of the initial effort estimates.