Tag Archives: product strategy

TheListeningResourceSusanEliot

Have a Clear Research Goal

Collecting the right data and analysing it effectively requires a clear research goal – understanding the reason why you carry out the work, and what you want to achieve. At the early stages of creating a product, your goal is likely to validate a critical assumption. This could be the product’s value proposition, the main revenue source, or an aspect of the user interaction design. Lean Startup captures the research goal as a hypothesis, and Scrum as a sprint goal.

Without a research goal you are in danger of collecting the wrong data, drawing the wrong conclusions, and moving your product in the wrong direction. In a sense, you are just trashing around hoping that the data will magically tell you what to do.


Separate Data Analysis from Data Collection

Once you have gathered the relevant data – for instance, by observing users, demoing a prototype, or tracking user behaviour using an analytics tool – step back, and carefully reflect on it before you make any decisions.

If you come from a Scrum background, then separating analysis from data collection may be new to you. In Scrum, data is traditionally collected and analysed in the sprint review meeting without always clearly separating the two activities. This carries the danger of rushing or skipping the analysis work, and making suboptimal or wrong decisions.

I hence recommend that you first collect the relevant data and then analyse it. Use the new insights to change the appropriate artefacts, for instance, your Vision BoardProduct Canvas, or product backlog, select a new research goal, and start the next cycle.


Keep an Open Mind

Keeping open mind may sound trivial, but clinging to an idea – not the lack of a fancy analysis technique or tool – is the biggest barrier to drawing the right conclusions in my experience. I know what I am talking about: When working on a new product, I feel strongly about my own ideas, and I sometimes have a hard time changing my mind. But being too attached to an idea, or being too eager to succeed carries the danger of rejecting any data that challenges it, which may well result in a poor product.

Before you carry out any analysis, take a deep breath and relax. Whenever you get tense or worked up about the data, tell yourself that it is not you, who is being challenged, but ideas, assumptions, and concepts. And ideas, assumptions, and concepts don’t have any pride; they don’t want to be right or wrong. They are just thoughts.


Mitigate Cognitive Biases

My fourth tip is to be aware of the cognitive biases we all have. A cognitive bias is a fault in our thinking causing us to draw the wrong conclusions. Confirmation biases, for instance, is the tendency to search for or interpret information in a way that confirms our preconceptions, and self-serving bias is the tendency to claim more responsibility for our successes than our failures.

Maybe the worst thing you can do when employing a framework such as Lean Startup or Scrum is to run iteration after iteration only to look for data that confirms your ideas – and to reject the rest. This is likely to result in late failure, which is just as painful as in a traditional, sequential approach.

A great way to mitigate cognitive biases is to analyse the data collaboratively. This tends to balance out individual preferences, believes, and preconceptions. Consider therefore involving the development team in the data analysis, particularly when you validate critical assumptions.


Clean the Data

Don’t forget to clean the data. Remove data whose quality is too poor to interpret it correctly, and discard irrelevant data. This should be easy enough – unless it’s an idea from an important customer or a powerful stakeholder. But saying yes to every idea is not going to result in a great product but in a cluttered piece of software with a poor user experience. As Steve Jobs once said:

Innovation is not about saying yes to everything. It’s about saying no to all but the most crucial features.

Stay true to your vision, and leverage your primary persona to determine the right features.


Pivot or Persevere

When analysing the data, ask yourself if it invalidates your strategy, for instance, the customer segment chosen, the product’s value proposition, the anticipated user experience, or the revenue source. If it does, pivot and change your strategy. This typically requires big amendments of your planning artefacts including the Vision Board and the Product Canvas. If your strategy is valid, persevere and refine the appropriate documents.

Pivoting is never easy, as it require us to accept failure, and to let go of assumptions and ideas we may have grown fond of. But it is often a necessary step towards developing a great product. If you find failure scary, then don’t take it personal, and don’t identify yourself with your ideas: It is not you who has failed, but an idea or an assumption has turned out to be wrong. That happens even to the likes of like of Einstein who famously said:

A person who never made a mistake never tried anything new.

But if you keep pivoting repeatedly, stop and reflect. Check if you are really moving towards a successful product, or if you are chasing an ever-changing dream.


Learn more

While there is more to data analysis then I can cover in this brief blog post, I hope that the tips above help you analyse your data and create a great product.

To learn more attend my Agile Product Planning training course. Please contact me for delivering the training course onsite, and in form of interactive virtual training sessions.

FearuredImageWorkingwithGORoadmap

Step 1: Do the Prep Work

Before you create your GO product roadmap, you should carry out the necessary problem validation work. Investigate the target group, the problem to be solved, the business goals, and the technical feasibility of your product. The Vision Board, the Business Model Canvas, and the Lean Canvas are great tools to capture and validate your ideas.

VisionBoardGOProductRoadmap

To see how this can work in practice, take a look at the Vision Board below. The board captures the idea of creating a digital dance game together with the intended audience, the benefits, the key features, and some aspects of the business model:

DanceGameVisionBoard


Step 2: Build the Roadmap

The Vision Board, Business Model and Lean Canvas are helpful tools to describe the market, the value proposition, and the business model. But they not tell us how the strategy will be executed. Will the first product version deliver the entire value proposition and generate the desired business benefits, for instance, or will this take longer? Say we focus the first version of the dance game on user acquisition. While this is a necessary step towards the vision, it does not answer the question when revenue will be generated. This is where the GO roadmap comes in.

I used the Vision Board above to create the roadmap shown below. You can download a PDF and Excel template by clicking on the picture.

DanceGameGORoadmap

The roadmap above takes the Vision Board contents, and shows how the strategy is executed over the next 12 months. It states the planned major releases with their goals, key features, and metrics. Version 1, for instance, is focussed on user acquisition, version 2 on activation and revenue generation. Version 3 is about retaining existing users, and version 4 targets a new segment and tries to acquire new users. (I discuss in more detail in my post “The GO Product Roadmap”.)

Your roadmap should tell a coherent story about how the product is likely grow: Choose the goals carefully and consider their relationships.

Which timeframe your roadmap should cover and how often you want to create a major release / new product version depends on your product. You should be reasonably confident about your roadmap and avoid speculation. You can regard the roadmap goals as hypotheses, but they should be informed assumptions, and not wild guesses.

If you cannot look further than the next release, then do not employ a roadmap!


Step 3: Derive your Product Canvas/Backlog

With your GO roadmap in place, you can now take the next step and use the product roadmap to stock your Product Canvas or product backlog. The GO roadmap provides you with the goal for the next major release, the two to three key features, and the metrics, which are a great starting point for discovering the product details including the user journeys, epics, the visual design, and the nonfunctional requirements.

GOProductRoadmapProductCanvas

The GO roadmap connects the Vision Board / Business Model Canvas to the Product Canvas/backlog; it links market insights and business model with the product. What’s more, the roadmap allows you to focus your Product Canvas/backlog on the next major release, which results in a smaller and more manageable canvas/backlog that is easier to change and update.


Step 4: Pivot or Persevere?

The process I have suggested so far sounds rather sequential: Do some problem validation work, then build the roadmap, and derive the Product Canvas to develop the product. This may give the impression that the GO product roadmap is a fixed plan that simply has to be executed. But the opposite is true.

Whenever we create something new – be it a brand-new product or new features – the one thing we can be sure of is that our initial ideas don’t work out as planned. As you collect feedback from users and customers on your prototypes, product increments, and MVPs, you should always ask yourself if your product strategy is still valid.

Say we expose an early prototype of the dance game to a test group. But unfortunately, we have to recognise that the kids are less excited by the game and playing it much shorter than anticipated. This data should make us rethink our strategy by asking ourselves if our market assumptions (segment and problems/needs) are wrong or if the user experience provided by the product is adequate. In both cases we have to pivot and change the strategy together with the product roadmap, as the following picture shows.

GORoadmapPivot

Note that the picture above assumes that the Vision Board / Business Model has to be changed in addition to the roadmap. That’s not necessarily true if the UX or features of the product are inappropriate but the market and business model-related assumptions are valid.

Be prepared to throwaway your existing GO product roadmap and to create a new one.

To minimise any rework, do the necessary problem validation work recommended in step one, and keep your product roadmap focussed and concise. The more details you add the more attached you become to your roadmap, and the harder it is to let go.

Once you have reached product-market fit and are confident that you are building the right product for the right people, I recommend you review and adjust your roadmaps on a regular basis, for instance every two months, as part of your portfolio management process.


Learn more

You can learn more about working with the GO product roadmap by attending my Agile Product Planning training course.

Please contact me for product roadmap workshops and webinars.

GORadmapFeaturedImage

A product roadmap is a high-level, strategic plan, which provides a longer-term outlook on the product. This creates a continuity of purpose, and it helps product managers and owners acquire funding for their product; it sets expectations, aligns stakeholders, and facilitates prioritisation; it makes it easier to coordinate the development and launch of different products, and it provides reassurance to the customers (if the product roadmap is made public).

Unfortunately, I find that many product managers and product owners struggle with their roadmaps, as they are dominated by features: There are too many features, and the features are often too detailed. This turns a roadmap into a tactical planning tool that competes with the Product Canvas or product backlog. What’s more, the features are sometimes regarded as a commitment by senior management rather than part of a high-level plan that is likely to change.

The GO Product Roadmap Explained

Faced with this situation, I have developed a new goal-oriented agile roadmap — the GO product roadmap, or “GO” for short. GO is based on my experience of teaching and coaching product managers and product owners, as well as using product roadmaps in my own business.

The following pictures shows what the GO product roadmap looks like. You can download a PDF and Excel template by simply clicking on the picture.

GOProductRoadmapExplained

The first row of the GO roadmap depicted above contains the date or timeframe for the upcoming releases. You can work with a specific date such as  1st of March, or a period such as the first or second quarter.

The second row states the name or version of the releases, for instance, iOS 7 or Windows 8.1.

The third row provides the goal of each release, the reason why it is worthwhile to develop and launch it. Sample goals are to acquire or to activate users, to retain users by enhancing the user experience, or to accelerate development by removing technical debt. Working with goals shifts the conversation from debating individual features to agreeing on desired benefits making strategic product decisions. The development team, the stakeholders, and the management sponsor should all buy into the goals.

The fourth row provides the features necessary to reach the goal. The features are means to an end, but not an end in themselves: They serve to create value and to reach the goal. Try to limit the number of features for each release to three, but do not state more than five. Refrain from detailing the features, and focus on the product capabilities that are necessary to meet the goal. Your product roadmap should be a high-level plan. The details should be covered in the Product Canvas or product backlog, and commitments should be limited to individual sprints.

The last row states the metrics, the measurements or key performance indicators (KPIs) that help determine if the goal has been met, and if the release was successful. Make sure that the metrics you select allow you to measure if and to which extent you have met the goal.

A Sample GO Product Roadmap

To illustrate how the GO template can be applied, imagine we are about to develop a new dance game for girls aged eight to 12 years. The app should be fun and educational allowing the players to modify the characters, change the music, dance with remote players, and choreograph new dances. Here is what the corresponding GO roadmap could look like:

SampleGOProductRoadmap

While the roadmap above will have to be updated and refined at a later stage (particularly the metrics), I find it good enough to show how the product may evolve and make an investment decision.

When creating your GO roadmap make sure you determine the goal of each release before you identify the features. This ensures that the features do serve the goal. Filling in the roadmap template from top to bottom and from left to right works well for me.

My post “Working with the GO Product Roadmap” explains the GO product roadmap in more detail including its relationship to the Vision Board, Business Model Canvas, and Product Canvas.

Wrap-up

The GO product roadmap provides a new, powerful way to do product roadmapping. Rather than focussing on features, GO emphasises the importance of shared goals. This makes it easier to communicate the roadmap, create alignment, and use it as a strategic planning tool that provides an umbrella for the Product Canvas and the product backlog. The metrics provided by the tool ensure that the goals are measurable rather than lofty and fuzzy ideas. Download the template now, and try it out!

You can learn more about creating effective product roadmap and working with the GO product roadmap by attending my Agile Product Planning training course. Please contact me for bespoke product roadmap workshops and webinars.

ProductPlanningArtefacts

The Three Planning Levels

Agile product planning comprises three levels: vision, product strategy, and tactics. The vision is the overarching goal, the product strategy the path to the vision, and the tactics are the steps along the way, as the following diagram illustrates:

The level of detail increases, as we move down from the vision to the tactics: Whereas the vision is typically captured by a brief statement, the strategy communicates different aspects including the market or market segment targeted, the product price and the channels, and the product’s unique selling points (USP’s). The tactics go further by describing the product details employing, for instance, user stories, design sketches, scenarios, and storyboards, as the following picture shows:

The Vision

Product planning starts with creating a vision: an overarching, shared goal that guides people. A sample vision from my own company is: “Grow Pichler Consulting without increasing headcount.” This vision may not sound mega exciting but it is very helpful for my team and me: It guides our work and focuses our efforts. Note that the sample vision doesn’t mention a specific product or service. It rather states a business goal. How the goal is realised is captured in the product strategy.

The Product Strategy

The product strategy is the path chosen to realise the vision. Without a strategy, making the right decisions about the product details is difficult: the functionality, the design, and the non-functional properties the product should exhibit. Having a strategy in place also prevents me from getting lost in the details.

I find it helpful to capture the target group, the needs addressed, the key features of the product, and the desired business benefits in the product strategy. But you may want to add the product price, the channels, the main competitors, and other important business model elements to characterise your strategy more comprehensively. As the strategy is a path to the vision, it may turn out to be wrong. This is particularly likely when a new product is created. Changing the strategy is also called a pivot.

The Product Tactics

The product tactics describe the product details: the product functionality, the user interaction, and the user interface design. Great techniques to capture these aspects are epics and ready stories, scenarios, design sketches and mock-ups, constraint stories, and sprint goals. New product features are best delivered incrementally so we can learn from the feedback we collect. I use blog posts, for instance, to create the material for my e-learning course. This allows me to learn from the feedback I receive, and to validate my strategy and the product details.

Product Planning Tools

I prefer to use the agile product planning tools shown in the picture below:

To capture my vision and the key elements of the product strategy I like to employ the Vision Board and the GO product roadmap. I use the Business Model Canvas to describe aspects not covered by the Vision Board such as partners, and customer relationship.

To capture the details, I use the Product Canvas. The canvas allows me to work with personas, epics, scenarios and storyboards, design sketches and mock-ups, constraint stories, sprint goals, and ready stories. For an incremental product update, a product backlog may be sufficient to capture the product details.

Wrap-up

Creating successful products requires more than attention to the product details. Ensure you have a shared in vision in place, and choose a strategy that guides you towards the vision. Use early feedback to validate if you are on the right path, if your strategy is valid. Let the product strategy help you decide what your product should look like and do.

You can learn more about agile product planning and creating a powerful vision and product strategy by attending my Agile Product Planning training course.

 “This is your last chance. After this, there is no turning back. You take the blue pill – the story ends, you wake up in your bed and believe whatever you want to believe. You take the red pill – you stay in Wonderland, and I show you how deep the rabbit-hole goes,” says Morpheus to Neo in the movie “The Matrix”. This quote reminds me of the choice we face when dealing with a new product idea: Should we walk away from it, or should we jump into it? And how can we tell?

To help product owners and teams decide if and how to progress an idea, I have developed a tool called the Vision Board. The board captures important assumptions that influence the product success, and it allows teams to start testing and refining their ideas. In this post, I explain how the vision board can be applied to kick-start the innovation process and to create a new software product.

A New Product Idea

I’ve recently had the idea of developing an electronic tool, a digital version of the Product Canvas. The canvas is a multi-dimensional product backlog that allows teams to properly capture the user experience including the user interaction and the user interface design. Since I published the canvas in July 2012, I have received lots of encouraging feedback. Some of it suggested an electronic version, and Johan Steenkamp started to work on a free, web-based product canvas as part of his BMFiddle.

After loosely collaborating with Johan for a couple of months, I was wondering if an enhanced digital canvas would be a good idea. It was like weighing up which pill to take: Take the blue one and leave the tool development to Johan, or take the red one and commit time, money, and energy? To help me make the right choice, I created a vision board for a new electronic product canvas. But before I introduce the board to you, let me briefly remind you what the vision board is all about.

The Vision Board Reloaded

The product vision board captures the initial ideas and assumptions for a new product, as the following picture illustrates.

The board above describes the overarching vision that guides the product. It states who should use and purchase the product (Target Group), why people would want to use and buy it (Needs), what the key product features are (Product), and why the organisation should invest money in the product (Value).

It’s important to understand that the vision board is intended to initiate the innovation process. It does not want to describe the users, the product, and the business model comprehensively or in great detail. It rather captures the critical assumptions, those assumptions that will make or break the product. More information is provided later in form of the Product Canvas and the Business Model Canvas, as the following picture illustrates.

Creating the Vision Board

To clarify my thoughts, I sat down and created a new product vision board. While I am a great fan of simple, physical tools, I decided to create an electronic vision board, as I wanted to share the board with Johan who lives in New Zealand, whereas I am based in the UK. Here is what I came up with:

 To create the board, I started with the vision statement keeping it intentionally broad. This allows me to follow the vision even if my electronic tool idea turns out to be ill conceived. At the same time, the vision reminds me that the new product is only means to an end: to help organisations create great products.

 Next I recorded my ideas about the users. In addition to product managers and product owners, individuals setting up their own business might find the tool helpful. As I am particularly unsure about this group, I have marked it in italic. I use this convention on the other sections of the board, too.

 I then focussed on the user needs formulating them as goals, for instance, being able to share the canvas with remote team members. Note that I have ranked the needs according to my current knowledge. Additionally, I have introduced a barrier: I believe that concerns about intellectual property and data theft may prevent people from using an electronic canvas. If the assumption is correct then it’s likely to have an impact on the solution and on how it is marketed.

 In the next step, I listed those product features, which I consider to be particularly important to create value for the users. I was careful not state a specific solution such as an iPad app, or a web app. This would be premature at this point in time and narrow down the options too quickly. Before I decide on the product specifics, I want to validate the needs of the target group first. As a consequence, the vision board may change based on the new insights.

 Finally, I stated the motivation for my business to invest in an electronic canvas tool. Similarly to the other sections, I have tried to focus on what I believe are the key assumptions and not be tempted to design the business model before I haven’t learned more about the users and their needs. After all, the business model will only work if the needs are met well!
I also found it helpful to state what I view as an investment barrier: If the electronic canvas tool incurs high running cost then this is likely to prevent me from funding the product development effort.

Validating the Vision Board

The next step for me is to validate my assumptions starting with the most critical one: the target group and the needs. I am planning to conduct a series of problem interviews focussed on the issues product owners and managers experience today when they identify, capture and modify requirements, as the picture below shows.

Problem interviews focus on the user needs, their goals and pain points rather than the product itself. In fact, it’s a good idea to exclude any product validation form the problem interviews, and not to ask, for instance: “Would this feature be helpful?” There are other research techniques, of course, for instance, observing users, but I am confident that interviews are adequate for now.

The interviews will hopefully help me validate my assumptions and allow me to learn more about the users. This should enable me to narrow down the solution and decide, for instance, to develop an iPad application, as well as help me find a viable business model. As Morpheus puts it: “Welcome to the desert of the real.” For as long as we just assume and hypothesise, we live in a dream world. By testing our ideas, we face reality.

Get Involved

If you would like to share your experience working with product boards, canvases, or backlogs, if you have any thoughts about what an electronic tool should do for you to capture, test and refine your product ideas, or if you have any specific questions about the Product Vision Board or the Product Canvas, then I’d love to hear from you. Please drop me a line either by email or via Twitter.

You can learn more about applying the product vision board by attending my Agile Product Management training course.