Product definition and roadmapping: from ideas to plans to products

Product definition and roadmapping is a key factor in the success of any product-based company. While most startups begin their activity with a nice idea or detecting a need in the market that has been unanswered and start their development rather “anarchically” or without a clear product in mind, there are a lot of tools and methodologies that can help them shape a product from the early stages of their activity.

Using a solid process to conceive and develop products can help them save both time and money and maximize the success rate; it is perfectly complementary to following a hunch.

 

Product definition and roadmapping: from ideas to plans to products

The process that will be presented in this article consists of 4 well-known steps, as many authors present the same differentiation – some of the most noteworthy include Roman Pichler (1):

 

Figure 1 – Product definition and planning phases.

This article aims to provide a review of the product definition and roadmapping process and present some techniques that can be used at each of its steps. And, before I jump into specifics, the set of techniques and the processes I will present here are the ones I use and work best for me, but I have no intention to paint them as the “best” methods out there. This is 100% subjective ?

The early idea: Transforming a hunch into a product seed

Hey! I’m sick of …”

“It would be nice to have ….”

It all starts here. Some room for improvement, some chance of innovation, some pain that can be relieved. In the previous article (2) I presented a product as something that satisfies the client’s needs. From a marketing perspective, it is a widely accepted definition of a product.

When we have this kind of “revelation” we tend to jump 3 years into the future and imagine what our idea could look like as a product, but the fact is that we don’t even know if people is willing to pay for it.

There are two things I like to do with these “early ideas”: to work with them a little bit in depth and see which kind of need they would satisfy, which people would be interested in them and why.

One of the first exercises one should do when coining the idea of a new product is to ask questions to the people, and in order to do that we first need to know who we will be asking these questions to. It is very important to have an initial knowledge of which is our market segment and get direct feedback about our product idea: we want to know if it could be useful, which are the expectations and how much our segment is willing to pay for it. There are a lot of nice tools that can give you this kind of info, but to start with a questionnaire using a Google Forms spreadsheet among your friends and families can be extremely useful and give you some initial estimate about the potential of your idea.

Another good exercise to perform early in the process it to find the position of our idea in our segment’s structure of needs. The Maslow pyramid (3) is a well-known hierarchy of needs system, but I find it too broad to apply it to a digital product. Almquist, Snior and Bloch proposed an extension of the Maslow pyramid in an article called “The elements of value” (4) that introduces a needs classification that is more fitting to digital products, as shown in figure 1.

What I find interesting about this last article is that the authors propose not only a pyramid that represents the priority of needs of the end users, but they also state which are the most valued attributes by the users depending on the market segment or product. One of their conclusions is that the companies that surpass their competitors take better care of the important attributes. Finally, related to this approach it is also noteworthy that Almquist et al. published a similar article in 2018 regarding B2B companies, “The B2B elements of value” – (5). It is quite interesting as well.

When we have an early idea that we want to turn into a product it is very important to have a clear initial concept of what our potential customer thinks of our product, what does the most value and how can we do better than the competition. We must keep this info as a top priority during all of the product’s life cycle and be open to adopting changes if necessary. 

Figure 2 – Elements of value pyramid proposed by Almquist et al.

What do we get from this step?
This phase aims to define the coordinates of our product. We have a concept, then we need to have an initial idea of which is our market segment and what are the most important attributes for its success, that is, the most valued by our users.

From a seed to a value proposition: Value Proposition Canvas and Kano analysis

At this point, we have a broad idea on what needs does our product satisfy, where it fits in the user value pyramid and which are the main attributes that our customers take into account.

It’s time to ask some questions:

• Who are our users/customers? (not only the market segment but also the habits, trends, etc.)
• Why would they want the product? Would they pay for it?
• What makes our product different?
• Could we build a critical mass to make the business sustainable and profitable?

With this basic information along with our early idea, a good practice is to map the value of our product with the needs of our customers – I use the Value Proposition Canvas (6), VPC henceforth.

Figure 3 – The Value Proposition Canvas (VPC) structure as presented by Osterwalder.

The VPC helps us map customer needs with our product proposal. It places the user on the right side – red circle – versus our proposal, on the left side (our value proposition). From right to left, we map what the user wants to do (jobs) with the product or services we offer (Products & services); what he likes with what we propose that can make him happy (Gains vs. Gain creators) and what he loathes with what will make him less sad (Pains vs Pain relievers). The left side of the value proposition canvas can contain some specific features, but also ideas to be elaborated in later stages.

This mapping comes straight from the information we retrieved in the previous step (our initial idea, the user feedback and the attributes that are valued the most in our sector, information about the competition, the questions we asked ourselves, etc.) and yields the basis of what do we have to offer, that is, what features or operations must be available with our product.

It is time now to start moving from the idea domain to the product features domain and propose the set of functionalities that our product will present. In order to do that, working with focus groups and brainstorming sessions are the tools that work best. I personally like to get on a room with the team and a small group of users and start writing down features on post-it stickers and put them in a wall, and afterwards group the ones that are related around topics, creating an affinity diagram, to gather what our product has to offer. (The process can be done in both directions, we can start sticking the main topics and adding features too).

Figure 4 – An affinity diagram on a wall, a very useful tool when brainstorming.

We must be very careful though. Up to this step, we have been actively pursuing the features or attributes that are valued the most by our customers, but a product is more than that; according to Kano (7), we can classify the features of a product in 3 groups: 

• Basic attributes: Features that must be in the product, otherwise the product will not be considered as an option by the end user. For instance, we could consider an integrated debugger in a development IDE as a basic feature.
• Performance attributes (or one-dimensional quality): A performance attribute is a feature that is related directly to the level of customer satisfaction. Following our development IDE example, having a fast and smart compilation process would be a performance attribute.
• Delight attributes. These are the qualities that are not necessarily expected (unknown needs) by the client but when added they positively impact customer satisfaction. These are the key features that will provide the biggest margin and the most powerful ones since the attractive features are the ones that will excite our users. Visual Studio’s live share, which allows users to do the remote pairing, is a nice example of a delight feature.

 

Hint!! – Build a shared product vision!
Brainstorming meetings to create feature affinity maps are a perfect opportunity to build a shared product vision and align all your team towards the same goal. The affinity meetings must have a moderator that accepts, discusses and explains each feature that is posted on the wall. My recommendation is to have the PO as the moderator of these meetins, and take this advantage to talk about the product vision and have each member involved in the process. Be visual, use tools, ask for feedback, etc. the meetings must be very dynamic!!

 

One of the conclusions of the Kano model is that the Delight attributes become performance attributes over time. This makes a lot of sense, since the user cannot be surprised all the time by the same thing; once the delight feature has been discovered and the user gets familiar with it, it becomes a performance attribute because the customer expects it in the next iteration … and in the competition.

Another conclusion is that basic features are something that our product must offer, otherwise, it will not be even considered by our target segment. This is critical to keep in mind when building the affinity map: the team has to study the competition and list all the basic features that our future product must contain, even if they do not provide any competitive advantage because they’re mandatory to keep us in the game.

The kano model is easily depicted as seen next:

 

Figure 5 – The Kano model.

The main aim to perform a Kano analysis is to label each of the features that we have gathered so we know which ones will help us match the competition, which ones will provide us with a slight edge and which ones are a competitive advantage.

Having all the features labeled will help us prioritize, analyze precedences between them, and have the necessary information to plan the introduction of the products in the market.

Hint!! – Fail early and fast
It is nearly impossible to nail a product concept from scratch. It is likely that the basic product idea is on the right track, but we’ve missed features or have a wrong approach or room from improvement. Involve the customers from the beginning. Get feedback as fast as you can. Be ready and open to change things and modify your VPC, topics, features or business model. The sooner you align your product with your customer needs, the better.

What do we get from this step?
The second stage of product planning gives us a specific list of topics and features, along with very valuable related information: How do these features please our users or answer their needs, and a label (Kano) that tells how the users will perceive these features.
At the end of this step we should be ready to plan how we will be delivering the features over time.

User Story Mapping

User story mapping was first introduced by Jeff Patton in 2005 (8). A user story map is a powerful and visual method to present how the user will interact with the product, displaying the topics and features that have been gathered in the previous step.

Patton made the following consideration on the use of traditional backlogs vs user story maps (9):

“We spend lots of time working with our customers. We work hard to understand their goals, their users, and the major parts of the system we could build. Then we finally get down to the details — the pieces of functionality we’d like to build. In my head I see a tree where the trunk is built from the goals or desired benefits that drive the system; big branches are users; the small branches and twigs are the capabilities they need; then finally the leaves are the user stories small enough to place into development iterations.
After all that work, after establishing all that shared understanding, I feel like we pull all the leaves off the tree and load them into a leaf bag — then cut down the tree.
That’s what a flat backlog is to me. A bag of context-free mulch”
Jeff Patton

 

My personal take on the user story map vs backlog is that both are 100% compatible – even complimentary in fact.

Figure 6 – Picture illustrating the difference between a backlog and a user story map.

But I do think that the user story map should be the starting point of the formal product planning.

To build a user story map, we will take the results of the previous step and do as follows:

• We will use a whiteboard or a wall and stick the topics we have discovered in the previous step. Each topic will be a header of a column; Patton calls them Backbone
• Below each topic of the backbone, we will stick all the features of the given topic from the top to the bottom of the wall.
• On the top row of the features, just below the backbone, we will be placing the stories that confirm the MVP of your product, that is the minimum set of features that are needed to bring the product to market. This is called the skeleton of the product.
• These features must be placed in order: in the previous step, we have analyzed the precedences between features (we don’t want to place “advanced filtering for the search” before we have introduced a “basic search feature “, for example). We’ll sort these features from top to bottom in order of priority.

Ideally, we should get something like this:

 

Figure 7 – Example of initial iteration of a user story map

Some reads suggest that the user story maps should also have a left to right order depicting the user journey order. My recommendation: don’t take this as gospel; there are indeed many cases where this is straightforward and directly applicable, yet on other occasions, the product has so many input points and flows that it just becomes too complex. Just try to sort from left to right what in your mind follows the logical path of the product.

What do we get from this step?
The user story map structures the affinity map and traces the timeline of each topic of our product. Once we have this, we’ll get a visual presentation of the critical parts of our product and a step by step display of how each feature will evolve over time.

Release planning

The final step consists of “slicing” (to honor Patton’s article) our product story map into releases. For this task, we will make use of all the information gathered in the previous steps: VPC; Kano labels and the user story map.

There are several rules that in my opinion should be respected in the release planning process:

• A release must always have a purpose and a clear goal.
• The specifications must be crystal clear.
• There must be a concise definition of done.
• Each release should provide an increment in the product’s competitive advantage.

There are 2 traditional ways of planning product releases, the traditional one would offer a balanced upgrade of all the topics of the product and an alternative would be to make a more significant increment on one or two topics in each release.

Figure 8 shows a release plan of the traditional approach, and figure 9 a release plan of the vertical advances.

 

Figure 8 – Example of a user story map sliced into releases, with a balanced topic release plan.

Figure 9 – Example of a user story map sliced into releases with an unbalanced release plan.

I personally like to remain open to both alternatives and combine them. Depending on the context (user feedback, market, and competition, etc.) we can opt for the most convenient one.

If we have a product with periodic releases (yearly releases for instance), we will provide a balanced yearly release, but depending on the market trends we can have unbalanced releases between the early ones that help us match a new feature released by the competition or bring to market a new functionality that places us ahead as soon as possible. 

Hint – How do we approach roadmapping
The key factor in product success is to be able to present features that make them different to their competitors and match the clients needs. In my opinion a release plan should always strive for some delight features that provide a competitive edge to a product, and cover the basic features. There are several factors that can affect a release plan: marketing campaigns or new features released by similar products that we must react to. The PO must have all the elements in mind when planning or adapting a release roadmap.

Product backlog preparation and development

 

Once we have defined the release plan, it is time to prepare the backlog and plan sprints and estimations. This is the final step of our planning, the point where all agile developers are familiar with since the process is very well known:

• The Product Owner briefs the team about the release goals and purpose, providing as much context as possible and making sure that all the development team is on the same page and has the same vision about the task ahead.
• The Product Owner reviews all the User Stories that belong to the release, makes sure that they contain all the necessary information and acceptance criteria and priority information.
• The development team along with the scrum master provides an initial estimation of each user story.
• The team prepares the sprints, assigning tasks and defining intermediate goals.
• The development cycle begins.

 

Conclusions: product definition and roadmapping

 

The previous sections have taken us on a journey that started with an initial intuition of what could be a product to the start of its development.

As I already mentioned, this is an approach that works for me and in my experience is similar to what most companies do, but it is by no means something written in stone.

It is also extremely important to keep in mind that all this process is alive and changing. The market will never stop to give us feedback, the competition will never cease to advance, and the trends will always be changing, and of course, our teams will be generating new ideas on a daily basis. The Product Owner has to juggle with all these factors and adapt the roadmap when necessary.

What I find more important is to have a well-defined process as a company. One of the most common pitfalls of new companies is to approach the product definition and roadmapping rather chaotically. This is often relieved by passion and hours, but when companies grow and have more experience, they understand the importance of this process.

There are several topics that have not been discussed in this text – UX/UI, the management of the technical debt versus the new developments, a discussion on how to approach prioritization, etc. – that have been left out for the sake of clarity and scope; I hope to present them in articles to come.

 

Bibliography: product definition and roadmapping

 

1. Pichler, Roman. Strategize: Product Strategy and Product Roadmap Practices for the Digital Age. s.l. : Pichler Consulting, 2016. 0993499201.

2.  Felip, Ramon. Product Leader – Not (only) agile. Apiumhub Tech Blog. [Online] 6 28, 2018. https://apiumhub.com/tech-blog-barcelona/product-leader/

3. Wikipedia. Maslow’s hierachy of needs. Wikipedia. [Online] https://en.wikipedia.org/wiki/Maslow%27s_hierarchy_of_needs.

4. Eric Almquist, John Senior, Nicholas Bloch. The Elements of Value. Harvard Business Review. [Online] 09 1, 2016. https://hbr.org/2016/09/the-elements-of-value.

5. Eric Almquist, Jamie Cleghorn, and Lori Sherer. The B2B Elements of value. Harvard Business Review. [Online] 03 01, 2018. https://hbr.org/2018/03/the-b2b-elements-of-value.

6. Osterwalder, Alexander. Achieve product–market fit with our brand-new Value Proposition Designer Canvas. Businessmodelalchemist.com. [Online] 08 29, 2012. http://businessmodelalchemist.com/blog/2012/08/achieve-product-market-fit-with-our-brand-new-value-proposition-designer.html.

7. Attractive quality and must-be quality (Journal of the Japanese Society for Quality Control). Kano, Noriaki, et al. Tokyo : s.n., 1984.

8. Patton, Jeff. It’s how you slice it. Jeff Patton and Associates. [Online] 01 2005. https://www.jpattonassociates.com/wp-content/uploads/2015/01/how_you_slice_it.pdf.

9. —. The new user backlog is a map. Jeff Patton and Associates. [Online] 2008. https://www.jpattonassociates.com/the-new-backlog/.

 

And don’t forget to subscribe to our monthly newsletter to receive more information about product definition and roadmapping. 

 

If you like this article about product definition and roadmapping, you may like:

Product Leader – Not only Agile 

The Product Owner role in software development  

Scrum for Product owners by Goskills

Some Agile retrospective ideas

Agile testing for beginners

Top agile blogs you should know about

A list of tools for Agile project management