Idea to a product backlog

So, you have a great idea but are struggling with how to begin? This blog should help you carve your journey from an idea to a product backlog.

There are 5 steps in this journey.

  1. Create a business plan
  2. Create OKRs
  3. Create product roadmap
  4. Validate technical feasibility
  5. Create a backlog

Let us dive deep into each of these 5 aspects. But before that, you can watch this workshop with b-school students (ISB Product Management batch) where we worked on taking an idea to a backlog.

1. Business Plan

A business plan articulates the customer and business value of a product. You need a business plan to begin with since you need funding for your idea and a validation therefore you typically present your business plan to a sponsor. Here a sponsor could be a VC or your company’s VP etc.

A good business plan has 10 elements.

  1. Problem derived from customer needs and insights

Here, the intent is to narrow down to a very finite problem based on customer signals.

Let us take a simple use case to discuss this business plan. Assume that we are all PMs with YouTube and we are getting some unfavorable signals.

Photo by Christian Wiediger on Unsplash
  • We have a lot of creators on YouTube.
  • These creators consider YouTube as a source of sharing content.
  • These creators also expect to generate a passive income
  • Advertising money has a significant lead time therefore telemetry shows that 80% of the creators drop before they reach 1000 hours of watch time
  • Only 10% of the creators on YouTube make more than $100 pm

The problem is that we are losing content creators to other platforms since we are unable to help them monetize their contributions early enough.

2. Personas

Personas are the various folks who may be impacted in this problem space. Whenever you think product, first think about the personas and their journey.

In our problem the two personas are:

  • Patron: who views and pays
  • Creator: who creates

3. Product hypothesis

More often than not, you will not find a clearly defined problem for you to solve to build a product. Therefore, you need to write hypothesis or assumptions that you are making to make this product. Try to tie your hypothesis to the personas you defined above.

For YouTube, I have 3 hypotheses written.

  • As a creator, I feel incentivized to create good content, if I get early opportunities of revenue generation.
  • As a viewer, my stickiness on the platform increases, if I get better content.
  • As a sponsor, I will be willing to pay the creator if I find value in the content.

You will observe that none of these hypotheses are product truths. These are assumptions that may go wrong.

3. Goal or metrics

Goals are important at this stage of product development since you need to be clear about what is your business objective. At times we end up building products that solve a customer problem but do not align with the business objectives. Such products, die a slow death since the CEO will never be excited about burning cash in a product that does not bring business.

For our YouTube use case, there are 2 metrics I am assuming Sundar Pichai must be interested in.

Produce high quality content

  • Ratio of (# of comments with positive sentiments : All comments)
  • Ratio of (# of subscribers / # of non-subscribers who watch content)

User stickiness on YouTube

  • Time spent by viewers on the platform for these creators will increase from xx to yy ms

4. Product solution

What is the product that you wish to build? You should be able to articulate it in words and in wireframes. Remember, visuals speak larger than words so as a PM you should be quick to wireframe something.

  • Creator workflow: Any creator gets the ability to get patrons to pay
  • Viewer workflow: Provide the ability for our creators to create and connect with the viewers where patrons can appreciate the creator
  • Patron workflow: Provide ability for the user to view and pay
Creator logs on to YouTube
Creator clicks on Monetization and sees the default Patron plans that YouTube provides.
Creator can edit an existing plan or create a new one. Editing a plan allows the creator to edit the name, price, and share some goodies with the patrons.
Viewer sees the PATRON button under a video
Viewer clicks that button and sees all the patron plans
Viewer clicks on the amount of money she wishes to pay
Viewer is redirected to payment gateway
Viewer becomes a patron and gets access to the hidden workflows

5.Market size

There are 3 numbers that should be of immense value to you when you are sizing a market. TAM, SAM, and SOM. In a nutshell, TAM is the total addressable market available. SAM is the market available to you. SOM is the market you can obtain. At the end of the market sizing, you should be able to come up with a dollar amount of what you can acquire in your business. More about this in an upcoming blog.

In our example, TAM, SAM, and SOM look as follows:

  • TAM: Total addressable market for content creators — $280bn [Video, Blogs, Podcasts, Developers, …]
  • SAM: Serviceable available market available for YouTube. $100 bn [minus Blogs, Podcasts, etc]
  • SOM: Serviceable Obtainable Market that YouTube can obtain. $24 bn [assuming that YouTube has only 24% of all video content market]
  • Revenue: Now content creators will make $24bn. How much does YouTube make == 5% service fee that is equal to $1.2bn


Financials here should be able to tell you 3 things. 1) The total revenue opportunity that we got from SOM. 2) The total cost of implementing the solution. 3) The total time of becoming break even.

In this use case, we have the 3 clearly listed out as


  • Development or engineering cost — Engineers, PMs, Designers, researchers’ salaries
  • Infrastructure cost — Cloud, Hardware, Software etc.


  • $1.2 bn

Breakeven time

  • xx months

When you calculate break even time, remember to consider the phase wise product roll out as well. Covered later in the blog.

7.Why should we invest now

This section talks about the urgency to invest in this space now.

  • In our case, the MoM growth of creators is declining which is a worrying sign.
  • Also, creators are preferring other streaming platforms, especially in short video segment therefore we need to incentivize the creators appropriately to ensure churn reduces and we are able to create a larger funnel for good quality creators.


A lot of folks confuse competition with direct competitors. That may not be the case. When I say compete, it could mean my direct competitors, allied services, some other product that may be solving a similar problem in another industry. Also, it is important to understand what you will do with the competitor’s information. The last thing you want to do with a compete is to follow a competitor because then you will always play catch up.

In our use case, there are some direct compete to video content creation:

  • TikTok
  • Dailymotion

Since we are in the funding space to creators, there are some competitors in that space as well:

  • Patreon
  • FundAnything

Now, I am also looking at related industries such as GitHub, a content creation platform for developers.

Now, what I learnt from my competition is something as follows:

Learnings from our compete:

  • With our direct compete maybe there is limited monetization abilities for creators
  • There is heavy reliance on 3rd party services
  • However, I see that GitHub that is a related industry has tested 1st party monetization services effectively
  • And I checked their user voice and I saw some great feedback from the creators. This helps me reduce the risk on some of my previous hypothesis.


If your product is built without risk, then it is just that you are not thinking hard enough. Risks help you identify what may go wrong and make you better prepared. This will also help you in your exit strategy and downfalls may not come as a surprise.

In our use case, we have 2 risks:

  • Hypothesis for willingness to donate as a patron is not validated.
  • Ensuring originality of content is necessary, else users may pay patronage to someone creating content inspired from others.

10. Asks

Of course, you cannot go to a VC without your asks. Be clear on what you want.

In our use case, I am going to Sundar asking for:

  • Funding of 1 feature crew for 9 months
  • Cloud credits to proceed with development and maybe use $xx of Google Cloud Platform
  • I need some senior level connections with payment gateway to choose the best one

Now, that your business plan is ready and assume that it is approved, you need to create a product roadmap.

2. Product Roadmap

Your product roadmap should clearly articulate what gets shipped by when. It should also detail out the dependencies with other teams. It should clearly articulate the possible go to market strategy. Remember, that your product roadmap may be 60% accurate at this stage but that should not deter you from creating one. Your product roadmap will be a live document that will continue to get updated as you go through the product releases.

In our use case, the product roadmap looks as follows:

3. Technical feasibility

For technical feasibility, you may have to work with your engineering team to ensure that what you are proposing is technically feasible. A high level technical architecture should be good to validate the feasibility of the solution.

In our case, I built something up.

If you are interested in learning how to create a technical system architecture, the you can follow this blog where we built Amazon search from scratch without having any prior tech knowledge.


Next, you should define your OKRs that allow you to measure success and progress. Here, O stands for your over arching objective and KR stands for the key results that will help you measure it.

In our case, the OKRs may look as follows:

  • Objective: Make YouTube the best platform for video content creators. [BHAG- It looks like a big hairy audacious goal]
  • Key result1: NPS for content creators should increase from 34 to 40
  • Key result2: Revenue from patron plans is $1.2 bn by EoY

You can learn more about OKRs in this blog.

Product Backlog

With your OKRs in place, you need to build your product backlog next. Your product roadmap should be a clear reflection of everything we have discussed above. Great backlogs have traceability, clarity, and predictability.

In our use case, I built a product roadmap that starts with the Objectives -> Key results -> Scenarios -> Features -> User stories

And this is how it looks like.

Objective -> Key Results
Key results -> Scenarios
Scenario -> Features
Features to user stories

Now, once the backlog is created, you need to start writing specs and then begin with engineering designs and coding.

I know this was long but, I hope this gives you a good understanding of the e2e journey from an idea to a product backlog. You must be exhausted after reading this so you can take a break and clap later.



Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store