Book review: Sprint (Part 2 – Day 1)

In my previous post I started looking at doing 5-day sprints to discover and test solutions for a problem that you’re trying to solve. This follows my reading of “Sprint” by Jake Knapp, John Zeratsky and Braden Kowitz. Once you’ve set the stage for a sprint, it’s time to kick things off: the first day of a sprint is all about agreeing on the challenge that you’re looking to have tackled by the end of the sprint. On the Monday, i.e. the first day of the sprint, the focus is on the following activities: (1) agreeing on a long-term goal (2) making a map of the challenge (3) asking experts and (4) picking a target.

Agree on a long-term goal (‘start at the end’)

You start the sprint by asking the the team “why”, make sure everyone is on the same page about what we’re trying to achieve. Why do we want to create this product? Why are we doing this project? Why do we want to solve this problem? Where do we want to be in 3 months, 6 months, 1 year, even 5 years from now and why? What will success look like? Agreeing on a long term will bring the answers together in a shared purpose.

Once you’ve got a shared understanding of the underlying “why” and have set a long-term goal, you come up with number of specific sprint questions, which you can derive from the assumptions and questions that the team might have. To get the team thinking about some of these questions, you can use the following prompts:

  • What questions do we want to ask in this sprint and why?
  • How will we subsequently utilise the answers to these sprint questions and outcomes?
  • To meet our long-term goal, what has to be true?
  • Imagine we travel into the future and our product or project failed. What might have caused that failure? How can we best mitigate this risk?
  • To reach customers for this product, what has to be true?
  • To deliver value to these customers, what has to be true?

Fig. 1 – Sample long term goal and sprint questions:

Long term goal: More people buying snacks online.

Sprint questions:

  • Are people looking to buy snacks online?
  • What is the experience customers are looking for when buying snacks online?

Map the challenge

Challange Map

Fig. 2 – Example of a Challenge Map: Flatiron Health’s clinical trial enrolment map – Taken from:

Creating a map is a great way to understand the steps the customer has to go through to achieve a desired outcome (see a good example in Fig. 2 above). Each map is customer-centric, with a list of key actors on the left. Each map is a story, with a beginning, a middle and an end. These are the common elements of a Challenge Map:

  1. List the actors (on the left) – The “actors” are all the important characters in your story. Most often, they’re different kinds of customers.
  2. Write the ending (on the right) – Write the outcome that the customer wants to achieve.
  3. Words and arrows in between – There’s no need for any fancy drawings; the map should be functional, and simple boxes and arrows should suffice.
  4. Keep it simple – Your map should have from five to around fifteen steps. If there are more than twenty, your map is probably too complicated.
  5. Ask for help – As you create the map, you should keep asking the team, “Does this map look right?” or “What are we missing?”

Ask the Experts

Nobody knows everything and it’s therefore critical that you engage with a range of ‘experts’. One of the biggest challenges of running a sprint is that you’ve got to gather a lot of information and make sense of it in a relatively short space of time. Having short conversations – approx. 30 minutes per conversation – with experts will help massively in collating relevant detail quickly.

Pick a Target

Selecting one target customer and one target event is the final activity of the first day of the sprint. The Decider needs to decide on the target customer and the customer event. Whatever she chooses will become the focus of the rest of the sprint – the sketches, prototype, and customer interviews all flow from this decision. Naturally, this can be a group decision, but it helps to assign decision-making responsibility to a single person.

Once you’ve selected a target, take a look back at your sprint questions. You usually can’t answer all those questions in one sprint, but one or more should line up with the target.

Main learning point: The first day of the sprint should really lay the groundwork for the rest of the sprint. Avoid the temptation to dive straight into solutions. Instead, spend the first day of the sprint to agree on a long-term goal and selecting a specific target to focus on!

Related links for further learning:


My product management toolkit (13): Continuous Discovery

I know it’s a bit of a bugbear of mine; people coming up with assumptions and jumping straight into solutions to address their assumptions:

“I know what my customers want” 

“I know that I’m right”

“I’ve got umpteen years of experience in this sector, I know what people want”

“We’ve defined all customer requirements, we now just need to implement”

These are some of the comments that I hear quite regularly. Hearing comments like these have made me even more determined to constantly discover.

Discovery is all about about truly understand what your customers want (and why) or validating your assumptions, checking whether what you think is actually true. I learned that “Dual Track Scrum” is a great way to do discovery in an efficient and a continuous way (see some visual breakdowns in Fig. 1 and Fig. 2 below). Marty Cagan introduced Dual Track Scrum, citing Jeff Patton as his inspiration. I don’t tend to get too hung up on the word “scrum”, because one might not always be working in a Scrum type fashion. It could be Kanban, XP or any other iterative development approach that you might be using instead.


Fig. 1 – Discovery feeding into Delivery – Taken from:

Instead, I like talking about ‘Continuous Discovery’, stressing that ongoing learning drives product development. Rather than doing big chunks of customer research at the start and at the end of the product development lifecycle, I prefer to learn ‘early and often’. The key is to spend some time understanding the problem first, before coming up with ideas or solutions to implement. With a ‘dual track’ approach, you’re constantly discovering and validating customer needs which can then be fed into the delivery of working software.

The outputs of a discovery track can come in all kinds of shapes and sizes:

  • A set of user stories and acceptance criteria
  • Design assets or wireframes
  • A prototype of a varying degree of fidelity
  • Learnings about user issues with working software
  • Data from a live experiment (e.g. A/B testing)

I often get asked why and when to best to use this Continuous Discovery approach and I thought to quickly summarise these FAQs:

Question: “Why can’t I just go and build stuff, launch and see what happens?”

My answer: I’d be the last person to stop you from building things, measuring and learn. However, I strongly believe that a large part of ‘continuous discovery’ is about mitigating (product) risk. Instead of spending a couple of weeks or months building something before you get actual customer feedback, I’d rather get customer feedback ‘early and often’, based on an product or a feature that has been used by actual users.

Question: “With these discovery sprints, isn’t there a big risk of ‘analysis paralysis’?”

My answer: No. By time-boxing and fixing the scoping of each discovery cycle, you can make sure that you constantly validate your riskiest assumptions or investigate things that can then go straight into the next development sprint. Each discovery cycle should result in a tested set of customer needs, user stories and/or wireframes which will then be converted into working software the following sprint.

Question: “Aren’t’ we just going over old ground?

My answer: From my experience, even if you have working software, by constantly testing it you’ll be able to fix bugs and develop a better product. It might seem tedious but I feel that this approach is a lot less risky compared to companies just doing a (soft) launch at the end of the development process and hoping for the best. Continuos discovery is not an alternative waterfall type approach,where you create additional stage gates and isolated process. In contrast, since development is still happening in tandem; you’re effectively discovering what needs to developing in the next iteration whilst people are building what you discovered in the previous discovery track.


Fig. 2 – Dual-Track Development – Taken from:

Main learning point: Instead of gathering customer requirements on a one off basis, I strongly recommend doing this continuously. Having designated discovery tracks that feed into development cycles will help in discovering customer problems and needs ‘early and often.’ This helps you in making sure that you’re building the right product for the right customer whilst you’re designing and building it.

Related links for further learning:


My product management toolkit (12): My 90 day plan as a product person

Soon I’ll be starting a new role as a Head of Product at a great FinTech business in London. I’m very excited about the role. There’s a lot of opportunity to make an impact and influence change. But where do I start? How do I prioritise change? These questions prompted me to start thinking about my 90 day plan for this role, identifying key steps and outcomes to concentrate on. I feel that the ‘3Ps’- people, product and process – are the most logical place for me to start from:


Objective 1: To assess current performance and ambitions of the people in the team and across the business; identify how I can help create the perfect conditions for them to do their day jobs and grow.

Key results:

  1. Individual audit and objectives-key results (‘OKRs’) – To understand strengths, weaknesses and development areas for each team member and have translated these into clearly defined goals and a personal development plan.
  2. Create a simple OKR measurement framework for team members (1) – I’m sure my new company will have a formal review framework, but I want to make sure that their specific quarterly objectives are measurable and are reviewed on ongoing basis beyond formal reviews once or twice a year. The goal is to make sure that personal OKRs are fully aligned with critical business goals.
  3. Create a simple OKR measurement framework for team members (2) – Even though OKRs aren’t necessarily meant to be a performance review tool, these will be very helpful in measuring and discussing personal progress. We can then make sure that individual OKRs align with overarching business and team objectives. I’ll have to make sure their objectives are highly measurable and feel somewhat uncomfortable, similar to the OKRs that I will set to measure my own performance (see example in Fig. 1 below).
  4. Hold at least 6 individual 1:1s with each of my team members within my first 90 days – Set a frequency and a clear agenda for regular 1:1s with my team members. I can imagine that different team members will have different preferences in terms of the frequency and content of our regular 1:1 sessions. I’ll agree this with my team members on an individual basis. I can imagine that our regular 1:1 sessions will cover a mix of OKR progress review as well any questions or issues related to day-to-day stuff.
  5. Establish and communicate team OKRs for the following quarter within my first 90 days – Agree with the team on max. 5 OKRs for the entire team for the following quarter. Share these OKRs – along with a related roadmap for the quarter – with the entire business by the end of my 90 day period at the latest.

Objective 2: To establish a product discipline within the wider technology function and communicate our role to the entire business within my first 90 days.

Key results:

  1. How does Product work with Technology, Design and Business Owners and why? – Agree with other ‘Heads Of’ and their respective teams on how to best integrate Product as a function, making sure the overall team structure reflects this. This agreement should be reached within 1 month from my starting, so that people have clarity about their roles and responsibilities.
  2. Communicate the role of product management, OKRs and team structure within my first 90 days – The goal is to make sure that everyone within the organisation know what the product team does and why. On a practical level, I want to make sure that people who sit outside of the product and tech team know who to turn to, when and why. I’ll be looking at the best way to (1) embed product managers within multi-disciplinary teams and (2) make these teams customer experience centric instead of just feature centric (see Peter Merholz’ great approach in Fig. 2 below).
  3. Talk to 100 people across the business in my first 90 days – The idea here is not to just have nice introductory chats across the business, but use these introductions to really learn about the direction of the company, views on products and customers. I might even ask the same questions in each conversation, almost like a mini research project to identify common themes (see Fig. 3 below). I will thus create a much better picture of key problems and opportunities to consider, which I can then feedback to senior management along with my related recommendations.
  4. Learn from at least 3 other product teams in my first 90 days – It will be good to learn from other product teams in different industries to compare notes on best practices, understand what worked well and what didn’t (and why).
  5. Shadow at least 10 different teams for at least 1 day in my first 90 days – In my experience, there’s hardly a better way to learn about a business, its products, stakeholders and challenges, than sitting with the different business teams. You can actively shadow your colleagues as they talk to customers for example (sitting with customer support is always a good one!). Equally, I’ve found that just sitting with a team on a regular and overhearing their conversations can give you valuable insights into to their worlds and their day-to-day challenges. This is something I strive to do on a continuous basis, well beyond my first 90 days, to make sure that I don’t develop tunnel vision.


Objective 3: To understand the current product portfolio and its fit with the needs of (target) users and against the market(s) the company is operating in.

Key results:

  1. Overarching business and product vision – What is the long-term vision for the business and why? How does this vision translate into a product vision? Is this vision well understood and shared across the business? I will work with the rest of the product team to work out how we can best drive this vision on a day-to-day basis and flesh it out so that it becomes a key driver for our products.
  2. Business strategy and business goals – Understanding the long and short business strategy is critical. Having an overarching vision is great, but it’s important to have context on how we’re looking to deliver on this vision. Which markets are we looking to target and why? Which customer segments are driving our vision and why? As a product person you might be closely involved in shaping the answers to these questions, but make sure you find out if you haven’t!
  3. Understand user, business, financial and market data – When looking at data, I’m planning on splitting my time spent on data in three different areas. Firstly, going through the company’s financials and forecasts to form a better picture of growth, profit margins and customer segments. I will then use this understanding to link back to the overall business goals – see above – and business strategy. Secondly, understanding our user segments, demographics and behavioural patterns will help me to better frame the problems or unmet needs to address. Thirdly, what does the overall market look like and how does it break down into specific customer segments? Who are our main competitors and what are their differentiators?
  4. Do a quick product (portfolio) audit – It will be interesting to really understand the value of the current value proposition and product portfolio. What problems do these products solve and for whom? Are there any customer needs or problems currently not solved by our products or services? If so, how do our (target) customers solve their problems or jobs without specific products or services in place?
  5. Talk to customers and partners – My goal is to speak to a good number of customers (B2C and B2BC) and partners in my first 90 days and beyond. This means developing good relationships with our sales and accounts people, who can help arrange short, problem interviews with customers. It will be my first foray into getting some real world feedback from our customers on, for example, how they currently use our products and why. I can then work out how to best engage with and learn from our (target) customers on an ongoing basis.
  6. Create a simple KANO model – I want to map our current products in a KANO model, identifying ‘hygiene factors’ and ‘delighters’ in order to get a better understanding of the competitive landscape (see Fig. 4 below).
  7. Explore competitive products and services, ‘mystery shopping’ – In my experience, mystery shopping is a good way to understand the competitive landscape and the differentiators of your own product or service. Using competitor products or observing customers using competitive products is a great way to learn more about user needs and your own product. How does your product or service compare to the competition? How does it benchmark?
  8. Study customer demographic and usage data, identify trends and patterns – I’ll definitely try to get my hands on whatever customer data I can get in order to learn more about customer segments and their behaviours. This will help me to understand trends and opportunities, identifying where we need to focus our product efforts and why.
  9. Identify which markets to target and why – Combining data on our products, our (target) customers and market needs to identify the best market(s) to target. This should also tie in nicely with the relevant strategic themes for the company, for example ‘internationalisation’, ‘partnerships’ and ‘retail’ and related business objectives.
  10. Use quantitative and qualitative data to create an experience map – Who are our users? Which jobs do they need to do and why? How do they feel about our products and services in relation to their jobs-to-be-done? Creating an experience map will help in understanding user behaviour in relation to our products and services. I’ve found the experience map exercise to be particularly helpful in relation to companies that don’t have a unified, shared view of their products or customers.
  11. Translate into a product strategy – Your initial product strategy can be fairly high level and you don’t have to lock yourself up in a dark room for 6 months to draft a plan. I believe it’s important to take your learnings and convert them into a plan which outlines how we can achieve critical business and customer goals, without getting too immersed in the detail. Instead, I tend to look at the high level milestones or building blocks that need to be in place to achieve specific business goals or solve customer problems. Melissa Perri recently wrote a really helpful article about how to create a product strategy, which I’ll definitely include in my toolkit (see Fig. 5 below).


Objective 4: To introduce the ‘minimum viable process’ necessary to address specific organisational or product related problems which impact product development or our bottom line.

Key results: 

  1. Is there a roadmap? Do we need one? – I know that some companies deliberately don’t have product roadmaps. Instead, they fully empower their product managers and engineers to liaise directly with customers and deliver against high-level strategic themes – companies like Hubspot are good examples in this respect. I, however, find having a product roadmap a very important tool in creating a product and customer centric culture across the entire business. A roadmap can be an incredibly helpful tool in conveying high level goals, milestones or themes to business stakeholders, teams and customers. I always make it clear that a product roadmap isn’t set in stone, but that it will give everyone in the business important context on what we’re looking to achieve and why.
  2. How do things get prioritised? – What criteria does the company use to add and prioritise things onto the roadmap. Are a product vision and roadmap in place that drive the roadmap? How do people assess new product opportunities? One the first things I’d like to do is to understand about any product or project milestones in flight or planned, and their underlying rationale.
  3. Product backlog, the next level down from the roadmap – Does the company have one product backlog or do the different teams have a number of backlogs that they work against? If so, what does the backlog look like, has it been ‘groomed’ and prioritised?
  4. How do things get shared across the business? (1) – Understand how people across the business know what’s going on from a product development and performance perspective. Often I see companies where product development is perceived to be a ‘black box’, with people being unclear about what gets developed (and why). I’ve also come across companies with a project management office that sends out status reports which are very task based and don’t necessarily provide a good update on the value we’re looking to create for customers or on tangible product progress. Like I mentioned in point 1. above, my preference is to have a high level product roadmap which is shared across the entire company (and ideally with customers as well). This acts as a simple but very effective example to convey why we’re building certain solutions or features and how we’re progressing against specific milestones or goals (see example in Fig. 6 below).
  5. How do things get shared across the business? (2) – Product review meetings, ‘all hands’ sessions or product retrospectives can also be a very effective in engaging with people across the business. The main reason why I’m always in favour of live demos over status reports is that people typically find it easier to see working software or a prototype instead of a written document. Even if you’re showing a non-finished article, you’ll at least be able to explain in person that a product or feature is still work in progress and what it is that you’re looking to learn (and why).

Fig. 1 – Sample OKRs to measure and review individual performance:

Instead of:

“To launch a new mobile app”

We will make the result more objective and measurable:

“To launch a mobile app for iOS and Android by the end of September ’16 and to achieve a 2% increase in mobile conversion by the end of November ’16.”

And make sure it’s aligned with key business objectives:

“To increase repeat purchase from 1.7 to 2.5 by 31 December ’16.”


Fig. 2 – Product managers embedded within multi-disciplinary product teams – Taken from:

Taken from:

Peter Merholz 1

Fig. 3 – Sample questions to ask during my first my introductory conversations in my first 90 days:

Generic questions to ask:

  • What is the overall vision of the company?
  • What are the key company goals or success criteria? What does success look like and why? Which one(s) are you working towards (how and why)?
  • How would you describe the company culture – what do you enjoy about working here, what could be improved?
  • Are you involved in developing new products or services? If so, how? If not, why not?
  • Who is your main customer? Is your customer internal or external? What do they care about and why?
  • What do you see as the main differentiator(s) of the business? Where do you see opportunities for the company or where are we lagging behind?
  • What are your observations with regard to the new products we launch to market and existing products that are already out there?
  • How do you currently collaborate with other disciplines within the company to deliver against company goals (e.g. working with traders, customer support or developers)

Questions about continuous improvement:

  • What does continuous improvement mean for our business and why?
  • Why is continuous improvement so important and what does success look like?
  • Have you got an example of where continuous improvement materially impacted the business’ bottom line? If so, how?
  • What kind of processes have you put in place to ensure continuous learning and improvement?
  • How do you go about instilling and maintaining a continuous improvement mindset across the wider business?

Questions about technology teams and leadership:

  • How do the developers currently interact with product managers, QA, UX as part of product development?
  • What is working well in that collaboration and what can be improved? Why?
  • What are the key roadmap goals or milestones for the coming quarter? How is success being measured?
  • What does the definition of “DONE” look like for the development team?
  • How and when do developers get involved in the planning process?
  • How do you currently structure your development team? For example, is it based on internal vs external, customer segments, specific problems, features or metrics?
  • (how) Do developers interact with customers?
  • Do you run a “dual track scrum” approach? If so, who gets involved in product and technical discovery?
  • How do you manage or mitigate technical risk?
  • What approach do you use with respect to testing? For example, do developers use TDD to test their code?
  • How do you balance fixing bugs, addressing technical debt with delivering business value, releasing new features?
  • How iteratively do the cross-discipline teams work? Is there a culture of continuous deployment?

Questions about customer experience and marketing:

  • How does marketing collaborate with product managers? When and how do marketeers get involved in the product lifecycle?
  • Who is responsible for developing a go-to market strategy? Who develops marketing strategies and related collateral?
  • Which customer profiles, segments and demographics are at the heart of our business strategy and why?
  • How do we go about reaching out to our target audience? Are there are specific areas that you are looking to optimise?
  • What does market growth look like and why? Are we looking at new – opposite or adjacent – markets?
  • What happens at the ‘initial insight’, ‘plan’ and ‘execute’ stages and why? It would be good to understand specific activities (e.g. story mapping, ‘jobs’, experience mapping, empathy mapping, etc.)

Fig. 4 – Create a simple KANO model – Taken from:



Fig. 5 – Product Strategy Canvas – Taken from:


Fig. 6 – Sample high level product roadmap – Taken from:



Related links for further learning:





No more features on product roadmaps – Have themes or goals instead!

You might have read my one of my previous blog posts about the so-called goal oriented roadmap. I  prefer goal-oriented roadmaps over their more traditional counterparts. My problem is that ‘classic’ roadmaps contain a mix of features and timings, but don’t provide any context whatsoever (I’ve included an example in Fig. 1 below). I typically don’t include features on a roadmap and focus on user or business problems instead. As such, the roadmap becomes a tool for ‘working backwards’ – enabling product teams to explore solutions for given problems or desired results.

I recently learnt from Jared Spool and Bruce McCarthy about adding “themes” to product roadmaps. McCarthy told Spool about the concept of adding themes, and Spool became an instant fan. Like me, McCarthy isn’t a fan of having features on a roadmap. Instead, he suggests adding “themes” to the roadmap and this is why:

  1. Open to ‘options’ –  McCarthy believes that by having specific features on a roadmap, you run the risk of sending a product team down a certain avenue (and closing off any potential side streets). For example, if you were to just put “data dashboard” on a roadmap, chances are you’ll end up with a data dashboard. However, what would happen if you were to put “provide our customers with data to make key decisions” or “no data access” on the roadmap instead? By focusing solely on solution you run the risk of falling victim to what Josh Wexler calls solution sickness. Solution sickness is all about fixating on a solution and ignore any alternative ways of solving a problem.
  2. Customer focus – Jared Spool makes a great point when he says “When companies talk about features, they are saying, “Look at us. Look at what we can do.” He goes on to explain that “When companies talk about the problems of customers, they are saying, “Look at what you’re dealing with. Look at how we want to help.” It’s very easy to get fixated on features and forget about the underlying problems you’re looking to solve.
  3. Helping trade-off decisions – One of the things I love about both the goal-oriented and ‘theme’ approach to roadmapping is that it forces you to consider ‘why’ you want to develop certain products or services. What problem are we looking to solve and why? Why do we feel this problem is worth solving? Why should we prioritise this problem over others? Both the goal oriented and the theme roadmap approaches help make customers and their problems the core of everything you do as a product person. When I use the goal oriented roadmap, I always take out the “feature” layer purely because I don’t want us to be pinned down to one solution.
  4. “Marketing the story of solutions” – Which do you think would be an easier story to sell to customers? Option 1: “You can now use this real-time data dashboard which you can access via your content management system, enabling you to filter the data and extract reports” or Option 2: “You can use our data to decide on whether now is good time to sell your house?” … Easy, isn’t it!? As Jared Spool points out, the ‘theme’ approach makes it much easier for marketing teams to tell a story about a product or service: “Here are the problems we set out to solve and here’s how we solved them.”
  5. A more cohesive design – Design is another area which is positively impacted by a shift in focus from solutions to problems. From experience, I know how much easier it is to prioritise against a problem that you’re looking to solve, instead of trying to cram in a lot of features which you think might have an impact. As Spool puts it: ” Without a commitment to specific solutions, the team has flexibility.” As a result, product teams stand a better chance of creating simpler, well designed products.

Main learning point: I really encourage all product managers – the ones who aren’t doing so already – to think much more in terms of user problems instead of focusing on features. Not only will this help you in focusing your product efforts, I believe it will also make you much more customer centric.


Fig. 1 – Example of a traditional roadmap – Taken from:



Fig. 2 – Goal oriented roadmap example – Taken from:


Related links for further learning:


Book review: What Product Managers Need To Know About Rapid Prototyping

“What Product  Managers Need To Know About Rapid Prototyping” by Mike Fishbein and Josh Wexler is a great ebook for any product manager keen on prototyping before building the actual product. Mike Fishbein is a content manager with Alpha UX and Josh Wexler is a solutions director at Originate. In this book, they’ve collated their learnings and tips with regard to rapid prototyping.

I’m currently learning how to create prototypes, using tools like Balsamiq, Illustrator, InVision and Sketch. Reading “What Product Managers Need To Know About Rapid Prototyping” felt very timely. These are the main things I learnt from it:

  1. Why do we need a prototype!? – Fishbein and Wexler point out very early on in the book that experiments are critical to alleviate risks inherent in new product or feature development. Prototyping is at the core of experimentation; it provides a quick way to validate your assumptions with real users and tackling key product risks early on in the process. It can be as simple as using a piece of paper with a sketch of a new feature for initial product validation. The main thing is that you use a prototype to mitigate risk by getting feedback early and often in the product (development) lifecycle.
  2. Why do product managers need to know about prototyping? – Building on the importance of experimentation, Fishbein and Wexler argue that “the product manager’s primary role becomes enabling experimentation as a seamless capability. At the core of experimentation is rapid prototyping.”
  3. Generative vs evaluative experiments – The distinction between generative and evaluative experiments is an important one. Typically, new products or features will start with “generative” experiments, where it’s all about identifying and assessing customer pain points or problems. In contrast, “evaluative” experiments are used to evaluate different options for a product direction. You’re evaluating a number of ways to resolve a customer pain point that you’ve established during a generative experiment. Rapid prototyping is critical during evaluative experiments.
  4. Consider constraints when prototyping – Using the words “prototyping” and “constraints” in one sentence might sound like a contradiction in terms, as you might think that prototype means having a free rein. In contrast, it’s important to pay attention to constraints when creating prototypes. The book suggests a number of important questions to ask before creating a prototype (see Fig. 1 below).
  5. Use a Learning Model, plotting ‘perception of value’ vs ‘simulation of value’ – Fishbein and Wexler describe the perception of value (‘PV’) as “a conglomeration of of metrics that together provide insight into comparative user feedback.” In other words, the higher the PV the better. Simulation of value (‘SV’) shows how close the user is to actually experiencing value. Going back to my earlier example of a simple sketch on a piece of paper; this might generate a high PV, because the user gets the value, but the SV is likely to be very low in comparison. It’s fair to say that higher SV values will generate more reliable user learnings and insights, as the prototype delivers more concrete value to the user.
  6. Plotting goals and constraints – It was really interesting to learn about plotting goals and constraints when thinking about creating a prototype. A good example of a constraint is “risk-threshold”, which represents the minimum amount of data you need to collect before your business gives the green light for a product. The ‘goal’ element covers the ‘why’ and perceived value of a product.
  7. Don’t forget about the ‘story’ – In addition to perception and simulation, Fishbein and Wexler also suggest looking at the ‘story’. The story dimension represents a continuum of the user’s narrative and how they might interact with the value proposition of a product. The book talks about about a so-called ‘double dip effect’, This effect typically occurs when product managers succeed in unlocking the ‘story’ element; when iteration cycles are so short that, following positive experiment results, product teams can run another experiment to understand the “why” behind the initial results. The key point here is that when prototyping becomes a rapid process, the product manager will be able to fully learn the narrative of her (target) users.
  8. Balancing simulation of value with iteration time and resources – Fishbein and Wexler also address some of the tradeoffs inherent in rapid prototyping. They point out that “prototyping lower simulations of value costs less and has shorter iteration cycles than prototyping higher simulations of value.” However, the insights you typically get from lower simulations of value are likely to be less reliable and detailed compared to high simulations of value. I’ve included Fishbein and Wexler’s pointers on how to manage these tradeoffs in Fig. 2 below.

Main learning point: I recommend “What PMs Need To Know About Rapid Prototyping” to any product person who wants to use prototyping as a way to learn quickly and often. Fishbein and Wexler have written a very comprehensive book which provides product managers with a great overview of dos and don’ts with regard to rapid prototyping. This book has definitely helped me in thinking about prototypes in a much more structured way!


Fig. 1 – Sample questions and constraints to consider before creating a prototype – Taken from: Mike Fishbein and Josh Wexler – What Product Managers Need To Know About Rapid Prototyping, pp. 19 – 21

  • What’s my or my organisation’s risk or treshold?
  • What’s my capability given my current budget?
  • What’s my organisation’s domain of discretion?
  • Am I over-constraining?

Fig. 2 – Balancing simulation of value with iteration time and resources – Taken from: Mike Fishbein and Josh Wexler – What Product Managers Need To Know About Rapid Prototyping, pp. 54 – 55

  • Stay in scope – It’s not about creating beautiful designs for your prototype, the goal is to learn about the user and their interactions with a product’s value proposition as early and often as possible. Staying in scope is therefore a key notion.
  • Adapt the methodologies – No (prototyping) methodology is set in stone. Instead, Fishbein and Wexler recommend understanding the high-level purpose of each prototyping step and then adapting it to your organisation.
  • Select technology that supports your best practices – When it comes prototyping, there’s a thousand and one tools to choose from. The important part is to make sure that prototyping is an efficient and waste-reducing mechanism for learning about users and validating new product concepts.

Related links for further learning:


Jeff Gothelf and Lean UX

In case you don’t know, I’m a big advocate of “Lean UX” and the work of Jeff Gothelf on this topic. It was Jeff who originally coined the term ‘Lean UX’ and wrote a great book about it, together with Josh Seiden. In short, Lean UX is all about not doing all your product design upfront, designing in more iterative fashion instead. I recently attended a talk by Jeff in London, where he talked about the concepts behind Lean UX, and here’s what I learnt:

  1. Cut out the design phase – Jeff stressed that the traditional design phase, where design is done in isolation, needs to go. I totally agree. Far too often designs are being thrown over an imaginary fence and implemented in a way that didn’t match the desired user experience, as intended by the designer. Instead, designers and developers should collaborate around ‘transient artefacts’, a simple sketch or prototype (see Fig. 1 below), in order to come to a shared understanding. These artefacts are by no the finished article, but create a shared understanding of what we’re looking to achieve and why.
  2. So what!? – The main idea about being ‘lean’ and ‘Lean UX’ is to “do less, more often.” Instead of just focusing on shipping features as often as you can, Jeff argued that the goal should be to achieve specific user outcomes as frequently as possible. I can imagine that this means a change in mindset and approach for some product teams. I believe, however, the ability to constantly ask the question “so what!?” from a user’s perspective is critical to building successful products. Whether you ship 2 or 50 features per iteration, this becomes totally irrelevant if you’re not changing customer behaviour.
  3. Humility and risk mitigation – I personally believe that as a product persona, you need to have a healthy degree of humility, and Jeff addressed ‘humility’ within the context of assumptions. He acknowledged how hard it can be for all of us to admit that we don’t know what the end state of a product or solution is going to look like, especially when you haven’t spent months creating a full product specification upfront. However, this is a risk that can be mitigated by being humble, acknowledging that you’re making assumptions and picking the riskiest assumptions to test first. In practice this will mean that you’ll be doing user research and getting feedback as part of each iteration.
  4. Change definition of “DONE” – Instead of just taking a feature release as the final stage of the definition of “DONE”, Jeff suggested that “changing customer behaviour” should be the ultimate definition of DONE. You pick a tactical metric that reflects the impact that the product is looking to make on customer behaviour. For example, you focus on a leading indicator to represent ‘customer intent’ or ‘conversion’ and something is only considered DONE if you’re moving the needle on your chosen metric (see Fig. 3 below).

Main learning point: I always learn something new from Jeff Gothelf and it felt no different with his recent talk in London. The main thing I took away from his talk was the importance of focusing on user outcomes instead and changes in user behaviour, as opposed to just shipping features.

Fig. 1 – Visual depiction of a transient artefact – Taken from: 



Fig. 2 – Acknowledge that we’re making a lot of assumptions when building products –



Fig. 3 – Build-Measure-Lean and Think-Make-Check – Taken from:

Think Make Check


IMG_2814 (1)


Related links for further learning:


Why I am a big fan of Dan North and behaviour driven development

I believe that “behaviour-driven development” (‘BDD’)  is one of those techniques that when you have done it once, you are likely to keep applying it. BDD was first introduced by Dan North, a well known Agile and Lean technology specialist, and is great tool for specifying and communicating the behavioural changes that one wants to achieve.

BDD typically starts with defining business or user outcomes, and then drills down into a feature set that will achieve those outcomes. The key elements of a story are: Title (one line describing the story), As a (role), I want (feature) and So (benefit).

For example:

Story 1

Title: Running out of ice cream alert

As an ice cream lover

I want to get an alert as soon as I am running low on ice cream in my freezer

So that I can order new ice cream and never have to run out of ice cream

A story is then accompanied by acceptance criteria, which are usually presented as “scenarios”. These scenarios are meant to help establish when a feature is “done”, or complete. The key elements of a scenario are: Title (one line describing the scenario), Given (context), And (some more context) and Then (outcome).

For example:

Scenario 1

Title: Number of ice cream tubs is running low

Given that I have turned on my ice cream alert

And there are less than 5 tubs of ice cream left in my freezer

When I open the door of my freezer

Then I receive an alert on my phone letting me know that I am running out of ice cream and I can order my ice cream and fill up my freezer

Now that I have given a quick flavour of what BDD is all about, let me explain why I am such a big fan of this approach:

  • It provides a common language through which people can communicate what it is they are trying achieve and the scope of the work involved.
  • It is an “outside-in” approach which means that the initial focus is on identifying the business and/or user outcomes, making sure people are clear on what ‘done’ looks like.
  • Stories and scenarios are testable, irrespective of whether testing is done in automated or manual fashion.
  • Defining stories and scenarios helps to spot any gaps or edge cases early on in the process, especially if you involve the key people involved from a range of disciplines.
  • None of these stories and scenarios are set in stone, but are likely to evolve and expand. This fits well with products that are developed in an iterative manner.
  • In my view, a good story or scenario is unambiguous in terms of the outcomes it aims to achieve and provides something which can be measured.

Main learning point: As much as I am a fan of Dan North and BDD, I know that there a lot of people out there who are less passionate about this approach. For example, they feel that BDD can be too prescriptive or test oriented. I would love to hear from (non) fans to learn how other people do or don’t use BDD and what they see as its main benefits or pitfalls.

Back to top