Exercises for Product Managers – Definition (2 of 2)

On the previous post Definition 1of 2 we reviewed the first exercises to start defining our product.

On this post will review how to write features and user stories and how to align them on a roadmap.

The goals of the definition phase are listed below:

  1. Create wireframes for a given product or project.
  2. Storyboarding to start user testing our product ideas.
  3. Organise the content on our product, following information architecture heuristics.
  4. Translate user needs into product features and user stories.
  5. Prioritise features and create product roadmaps aligning the team and the company.

We adequately dealt with the first three goals in the Definition 1of 2 post, we will focus on the last two goals.

Exercise 1. Product feature breakdown

As an example check the features that make useful Googles Inbox email editor:

  • Feature: Recipient text input box – User need: send email to a known email address.
  • Subject text input box – User need: to add brief summary of the content.
  • Close button – User need: to close the email window.
  • Send button, delete button, text styling, and other features.

Screen Shot 2018-09-25 at 22.31.37.png

Agile Alliance defines the Minimum Marketable Feature as a small, self-contained feature that can be developed quickly and that delivers significant value to the user.

The following graph explains exactly what we want to achieve by breaking a complex peace of work into Minimum Marketable Features. The aim is to release to the customer the smallest amount of code to get feedback from real users as early as possible, it is known as Lean methodology.

Image result for minimum marketable feature

An effective way to describe a feature is by using the following factors:

  • Problem to solve
  • High level solution
  • KPIs (Key Performance Indicators) measurable outcomes when the feature gets launched

An example would be:

  • Problem (or need): email users need a way to format the content of their emails.
  • High level solution: a button should contain the most common functions used when editing text such us bold, italics, underline.
  • KPIs: the rate of number of emails styled to not styled on Inbox will be similar to the rate observed in Gmail i.e. 20%.


  1. Think on an app that would allow you to order alcohol to your door (wine, beer, liquor).
  2. Brainstorm how to breakdown into features.
  3. Explain briefly for each feature the Problem or need they are tackling, high level solution and measurable outcomes when released to the market.

Exercise 2. User stories

  • A way to capture User Needs.
  • Shared with the development team and stakeholders.
  • A way to broken up large features into smaller user stories.

The format of the user stories is:

  • As a {type of user},
  • I want to {goal},
  • so that I can {reason}.

On the email example a user story could be:

  • As a business user,
  • I want to enter the email quickly,
  • So I send it faster


  1. For one of the features from the previous exercise.
  2. Identify the user needs and write out user stories for them.

Exercise 3. Acceptance criteria

Acceptance criteria is what the product needs to do to mark this user story as complete.

The format of an acceptance criteria is:

  • Given {scenario}
  • When {action or change}
  • Then {effect}

The “Given” stands for that which is provided already, the “When” is the instance a use comes up and the “Then” is the result of engaging the product.

This format is called Business Driven Development, and normally the acceptance criteria are written in close collaboration between Product Manager and the Automation Test Engineer.

All written scenarios get embed in the code on a the feature file of test frameworks such as Cucumber:

example Feature File
Srccodes.com – Cucumber Quick Start Guide
This is the way high level features gets drilled down into actual code!


  1. For one of the user stories from the previous exercise.
  2. Write the necessary acceptance criteria that would make you confident the user story is ready to put on user hands.


On the Agile world work gets broken down into:

  • Epics: is a large piece of work or objective which is normally given by the business, i.e. home page redesign, checkout improvement, integration with payments partner,…
  • Features: is the smallest, self-contained functionality that can be developed quickly and that delivers significant value to the user.
  • User stories (Product Backlog Item on below illustration): is a way to explain effectively user needs within a feature.
  • Acceptance Criteria: are the check points that a user story must accomplish to be released.

Exercise 4. Product roadmap

A product Roadmap is a communication tool that helps in understanding some vital information during the whole lifecycle of a product and feature.

The goals of a product roadmap are:

  • Internal communication of what and when will be delivered
  • Team alignment
  • Resource planning
  • Highlight dependencies and risks
  • Stakeholder buy-in
  • Future vision

The following picture illustrates the way to plan a roadmap following Lean methodology:


On every release there is user feedback and measurable outcome that can be used to learn and improve the following release.

Example of a roadmap for an eCommerce website planed following Lean methodology:

Screen Shot 2018-10-06 at 21.49.29.png
Example roadmap


Create a roadmap for an eCommerce company.

  1. Think of which main epics and features will be needed to build an blockchain wallet.
  2. Group the features in releases.
  3. Draft a roadmap which communicates the rough timelines and what will be the measurable outcome on each release.


  • Aha.io worlds number one roadmap software
  • Powerpoint and Excel (templates here Daykem.org)

* Copy of the roadmap on the above image:

  • Landing page (using third party tool i.e. launchrock.com)
    • Goal: to get early leads and make sure there is enough interest.
    • KPI: 10% of visitors join the waiting list.
    • Effort: Small
    • Development Starts: September
    • Release: September
    • Status: Done
  • Basic Catalogue web page, submit order and pay by link through email using i.e. Paypal.
    • Goal: start offering services to our leads, converting them into actual customers.
    • KPI: 20% of our leads submit an order within the first 30 days.
    • Effort: medium
    • Development Starts: October
    • Release: November
    • Status: In progress
  •  Adding checkout functionality including card payments.
    • Goal: improve customer experience. Increase conversions.
    • KPI: 30% more conversions compare to pay by link.
    • Effort: Medium
    • Development starts: December
    • Release: January
    • Status: Not started
  • Fulfilment third party integration
    • Goal: Automate the shipping process saving costs
    • KPI: To be confirmed
    • Effort: To be confirmed
    • Development starts: To be confirmed
    • Release: To be confirmed
    • Status: Under consideration

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s