Skip to content
memo.d.foundation / topics / product-management-basicsConnect

Research notes/Engineering practice

Product management basics, from roadmap to feedback loop

How a product team decides what to build next, covering the roadmap, data-driven feature definition, the Kano model, feedback loops and building in public.

Use with AI

Every product team keeps facing the same question: what should we build next? These notes cover the tools that answer it. A roadmap sets the plan. Data and customer feedback show which features deserve the investment. The Kano model ranks the candidates. A feedback loop keeps the answers current, and building in public brings users into the process early.

Merged and rewritten by neko-anon, the Dwarves editorial desk bot, from older notes in the research archive.

1The product roadmap

1.1What it is

A product roadmap is created at the beginning of product development. It is a list of features with an execution timeline.

It outlines the vision, direction, priorities and progress of a product over time. It is a plan of action that aligns the organization around short- and long-term goals for the product or project, and how they will be achieved.

From a roadmap, the development team can create a list of follow-up todos, analyze the priorities in detail and execute the core features first.

1.2Why it is vital

1. Remove the uncertainties. A roadmap is a blueprint of what to do. Developers do not have to worry about what comes next. People know their job, how to get there and what to prepare for at each point.

2. Budget planning and resource allocation. With a roadmap, developers can calculate the effort each milestone needs and arrange the right resources. For products that rely on external investment, the roadmap is what you show investors when you ask for the right budget.

3. Priority. The roadmap keeps the team on track. It lists features by priority level, so the development team can look it up and pick which one to build. It forms a consensus inside and outside the team. Teammates agree on the product features, and users know what to expect.

1.3The structure

1. Product description. Describe what the product does and how it works, at the most basic concept level.

2. Product goal. Explain which problem the product resolves, and how different things will be before and after using it.

3. Product features. This is the most important part: which features the product needs to deliver the functions in the description. Each feature must come with a use. Based on the product goal, developers choose the aligned features to finish.

4. Estimated timeline. The schedule that measures execution progress and makes sure each feature ships on time.

5. Product milestones. Development must be divided into milestones. They break the large goal into smaller achievements, so teammates can arrange their time and effort to meet the goal effectively.

2Defining features

This phase usually happens after the MVP stage. Once the idea is validated as an early version, product owners tend to get overwhelmed by feature requests and by the number of ways to develop the next highlight. It becomes hard to decide which feature deserves the best investment.

Four rules help:

  • Use data. Data does not lie.
  • Data alone cannot provide all the information. It tells you what is happening, but you have to figure out the why. Data plus customer feedback gives you the next decision.
  • Develop a relationship between the customer journey and the product.
  • Define the core metrics, then develop those.

2.1Data analytics

Keep a dashboard of how the data flows. Collect everything that exists. Understand the usage ratio and how customers engage with the product through numbers and facts. This drives a point of view on what affects user behaviour. Effective tools are Google Analytics and Mixpanel.

The data collected for your product is also a goldmine for identifying what to build next.

2.2Find the highlight metrics

Metrics are everywhere and appear in many forms. For each product to meet its business goal, it should have some core metrics that define the product's value. Focusing on the right metric saves time when prioritizing features and measuring their impact on users.

3The Kano model

The Kano model defines the essential level of the next features. It splits a product's features into three levels:

  • Threshold attributes: the basic functions. Users expect them.
  • Performance attributes: not strictly necessary, but they increase user retention.
  • Excitement attributes: additional functions that make the product different.

Here are the three levels applied to a cellphone camera:

attributesdescriptionexamplepurpose
thresholdbasic functionsback cameraenter the market
performanceupdate UXfront cameramaintain the market
excitementdelight usersQR code scanexceed as pioneer

The model then maps these levels onto two metrics:

  • Customer delight: how much the feature improves the customer's UX.
  • Implementation investment: the cost to build and maintain the feature.

3.1How to run it

  1. Brainstorm all possible features.
  2. Categorize them into the three levels.
  3. Make sure you keep the basic functions.
  4. Remove irrelevant, indifferent and duplicate features.
  5. Consider turning performance features into excitement features.
  6. Evaluate the implementation cost.
  7. Assess the user segment against the cost they can afford.
  8. Map the result into the product roadmap.

3.2When to use it

The goal is to prioritize which feature to work on next. It fits when time is limited, resources are limited, you are testing the market, or you are shipping a minimum feature set. My best guess is that this makes it a startup and MVP tool.

4Feedback loops

A feedback loop is the process of watching users use your product, seeing how they respond, collecting their reactions, putting them into measures, listing the pros and cons, and pivoting to improve. In short, you collect users' opinions on your product and use them to make it better.

4.1How it drives growth

  • It shows that you care about your users.
  • It gives objective opinions, which are real and rare.
  • It validates the product idea: whether the product fits the market, how it compares to its competitors, and how users behave.

Then you build the next version and focus on those metrics.

Constant talking and feedback seeking show customer care and gradually build trust between users and the product. Feedback can come from automated emails, community build-ups or a casual ping to ask what is on their minds. As with building in public, the more transparent you are, the easier it is to get feedback and improve.

4.2Create a feedback loop

A loop serves three purposes.

1. Gather data

  • Select relevant channels where users interact.
  • Run customer interviews.
  • Send email follow-ups.
  • Run surveys.

2. Analyze data

  • Set up tracking metrics.
  • Select core metrics.
  • Analyze the data to see how to improve those metrics.

3. Make data useful

  • Adjust the product if the feedback conflicts with the product goal.
  • Inform users about the change.
  • Thank them for their contribution. That closes the loop.

4.3Examples

Hubspot and Traveloka are, I suppose, the two best examples of customer service and feedback loops. They respond quickly and follow up when the waiting time for a service stretches. Users know exactly where to drop feedback or look up FAQs.

5Build in public

Build in public (#buildinpublic) is a process where creators are transparent about how they build their product. They narrate how they got there and what they do during creation. They publish everything transparently, even when it gets nasty and lame.

5.1The purpose

Traditional launching has a problem. Makers publish the product once it is done and ready, and users then need a while to get familiar, find a shared rhythm, see the useful points and start adopting it.

Building in public enables testing with beta users. Makers receive feedback and adjust accordingly. People love to hear stories and to be part of one. By the time the product is ready, makers have two things:

  • A fine-tuned, market-fit product.
  • A community that loves the product and expects to put it to real use.

5.2The process

It is simple: when you do something, share it publicly. I was trialling it with Readify, a reading platform that features highlight articles based on interest. The steps were:

  1. Answer the what. What is the current problem?
  2. Describe the how. How do we resolve it, and what benefit does the product bring?
  3. Explain the purpose. A community is made of things its members have in common, either something they fancy or something they are against. Find that, take it as the purpose and serve it to the community. That is how loyal users get convinced.
  4. Confirm the process. Share the kick-off of development, and the roadblocks and obstacles.
  5. Announce the product. Introduce the beta version. This gathers potential users and brings in the first feedback.
  6. Update the change. Update the features and changelog, which shows users that their feedback matters and that the improvements are based on it. Update the usage status too: numbers, geography and the status quo.

6References