Tag: Sprint Review

Posted on

Hands-on Agile 42: Lean Roadmapping and OKRs — Janna Bastow

The value is in roadmapping not in the roadmap itself

When you use roadmaps, you are making a number of assumptions:

  1. You assume you know how much work there is and how long each feature is going to take.
  2. You assume that nothing else is going to disrupt your timeline.
  3. You assume that each feature will work as soon as it is launched.
  4. You assume that each of these features actually deserves to exist!

What could possibly go wrong?

  • Made up release dates
  • Development due dates marches
  • Mismanaged expectations
  • Missed market opportunities
  • Building the wrong thing
  • Sad product managers

Vicious cycle: big buffers, slow work -> tighter controls, less freedom -> quality suffers, problems go unsolved -> blame culture -> repeat…

Your roadmap is a tool to help you learn and iterate at the product strategy level. In other words: Your roadmap is a prototype for your strategy.

Keep your roadmap simple!
My First Roadmap: Problem 1 -> Problem 2 -> Problem 3

Metaphor: Product is uncharted territory. Survey your surroundings, and what is at your disposal. Take one step at the time and map your journey on observations. Now -> Next -> Later.

Now: granular about your focus and scope. Stuff right in front of you

Later: less about spicific initiatives, outlining problems you think might need to be sovled to reach your vision.

The company sets top-level objectives (north star), and teams work together to decide how they can work towards this goal. Metaphor: get to Mordor: you can have my axe, bow, sword.

Objectives might be set on different levels. Some companies have more than one product, department, etc. E.g. Generic objectives, Pirate (ARRRR) objectives, etc.

Vision is essential too: FOR target customer, WHO statement of need or opportunity THE product name THAT key benefit, reason to buy UNLIKE primary competitive alternative OUR PRODUCT statement or primary differentiation.

Vision + Objectives + Time Horizons = Lean Roadmap

Objectives (what you need to achieve: improve overall health to avoid illness or injury) -> Initiatives (actions we need to take to get there: introduce regular exercise to schedule; refactor diet) -> Key results (what good looks like: lose 15 pounds by the end of the year; be able to touch toes without bending knees)

There are lots of paths forward, leave room for interpretation and creativity!
(e.g. set a meal as a goal, not a steak). And don’t forget to build in room for validation. (validate what you have delivered)

It’s not your job to have all the answers, it’s your job to ask the best questions!

Posted on

Jeff Gothelf: Outcome-Based Product Planning — Hands-on Agile 43

“Roadmapping is a flawed concept in the age of Agile. Maps, by their definition, are linear, and we don’t build linear products and services anymore. We build continuous systems.”

The Outcome-Based Product Plan:

  • Step 1: Change the question we are asking
    Old question: what will be built? (output)
    New question: what will people be doing differently if we succeed? (outcome)
  • Step 2: Change how we view our work
    We must change our perspective and view work from the outside in. (customer-centric view). Instead of giving you a possible solution, let me understand what problem you are having first.
  • Step 3: Change the destination
    “A roadmap is a marketing tool with your plans for the coming quarter and year” -Tami Reiss.

Objective overall, key results per quarter.
Jeff uses a nice fog metaphor to explain the focus of this way of working.

How to write your first OKR?

  1. Start with a clear business problem.
  2. Turn the business problem into a positive goal. (objective)
  3. If you solve the problem, what will people be doing differently? (key results)

    Determine the risks in your ideas and design experiments to test them. (nice example of bike racks in Rotterdam)

    Quarterly Check-ins:
    – How are we trending toward our quarterly key result targets?
    – What are we learning?
    – Are there hypotheses we’re currently working on proving true? False?
    – What will we keep funding?
    – Where will we pivot?
    – What will we kill?
    – What will we add to our backlog?

Outcome-based product planning explicitly requires teams to do product discovery!

Challenges to expect, and how to overcome them:

  • Pushback and anxiety – the team is going to determine what to do based on data/experiments.
  • What they will keep doing: defining & clarifying strategy; setting guardrails and scope; making key decisions; removing obstacles; facilitating team success.
  • As a team, practice radical transparency; over-communicate; support decisions with data; reinforce key results as goal; check in after every short cycle.
  • Sell the benefits, not the feature; speak in outcomes; outcomes have financial impact (example how Apple sells their products)