Aug 13 2017 - Roadmaps are linear. Software projects aren’t.

Roadmaps are linear. Software projects aren’t.

View this email in your browser

15 5-star reviews for Sense & Respond:"some great case studies and an extraordinarily clear case for the application of lean/agile methods across business. I'll certainly be recommending Sense & Respond to every manager I know." Don't have a copy yet? Grab a copy here and buy one for your boss too.

Hey folks -

In last month’s newsletter I showed you how to take metrics that executives care about — revenue, sales, et al — and humanize them into customer-centric behaviors known as outcomes. This mapping of impact level metrics to outcome metrics brings the customer back into every conversation focusing the company’s efforts on increasing the success of your customers. This month, I want to build off that concept and discuss how to build roadmaps from these outcomes.

Software is an uncertain medium. It’s a continuous medium. This means there is no end to it, you can’t predict it’s end state and you really have no idea what combination of code, copy and design will deliver the customer success (outcomes) you’re seeking. Your planning efforts will undoubtedly change as new insight emerges from your build/measure/learn efforts. It’s easy to commit to roadmaps because they *seem* rational on their own but as I showed in this talk at Google back in 2014, reality is much different.

What we promise:

What actually happens:

So if we’re trying to make customers successful but their behavior is unpredictable and the value of what we’re shipping can’t truly be known ahead of time, how do we plan our product development efforts?

As legendary software developer Kent Beck tweeted, we have to change our perspective of what goes into a roadmap:

Here’s how to do that:

1. Get your product managers, designers, devs and business leaders in a room with the most current set of planning tools (typically roadmaps).

2. Take your current feature-based roadmap and remove the timeline from it leaving only a list of things you believe you should build this quarter/half/year.

3. Have everyone in the room generate post-it notes for each feature with a customer-behavior they hope a successful implementation of that feature will yield. The key question to ask here is, “If we build and design the best possible version of this feature, how will we know?â€

4. Now have everyone in the room cluster (aka affinity map) the post-its into similar groupings of desired customer behaviors.

5. With (hopefully) a handful or so desired customer behaviors we now set out to prioritize them. “What is the most important thing we want our customers to do (or to do more of) this year?†Use a dot-voting approach or some other method come up with a stacked rank of what you’d ultimately like your customers to do this year.

6. Based on that prioritization, the team now lays out each behavior on the roadmap timeline. Here’s the key, instead of re-mapping features back to the behaviors, put each behavior on the roadmap as a question, “How will we get customers to increase the number of items in their shopping cart per visit?â€

7. You can use the outcomes you generated in the exercise from last month’s newsletter as the measures of success for each deadline in the roadmap. So now your questions look like, “How will we get customers to increase the number of items in their shopping cart by 50% per visit?â€

8. The features you had on your original roadmap can now serve as assumptions the teams can test during each quarter to see if, indeed, they do move customer behavior in the desired direction. But these are not the teams’ only options. They can come up with any idea that will help answer the question on their roadmap.

What you’ve done with this exercise is give your teams room to explore, experiment and learn which ideas make customers more successful. Instead of tying them to specific features and deadlines (a guaranteed recipe for failure) you’ve encouraged them to engage with your customers, learn from them and let the best ideas emerge from the system. Their measure of success no longer becomes shipping a specific feature on a specific date. Instead it becomes meaningful changes in customer success.

A quick caveat (that likely requires more than just a quick note but this newsletter is getting pretty long already): Building feature-based roadmaps makes life easy for managers. It’s easy to point to a date and feature and ask, “Is it done?†Based on the answer it’s easy to determine whether the team deserves a reward or not. When your roadmaps change to questions about outcomes, the answer will rarely be binary. It will be something like, “We increased the number of items per cart per visit by 38%. Our goal was 50%.†As a manager you’ll need to prepare for these situations where determining whether further effort is required won’t be so black and white.

What do your roadmaps look like? Are they lists of features? If so, how can you move them to lists of questions?

[Jeff]@jboogie[email protected] 

P.S. - You can now hire me for short, remote consultations 30 minutes at a time. Get started by picking a time here that works for you.

———————————————————————————————

Book News

Sense & Respond continues its 100% 5-star review streak. Will you write a review once you've read it? Research Archive Made Public: Head on over here and find over 1000 links to primary and secondary research we collected over the 2 years we spent writing Sense & Respond.———————————————————————————————

Upcoming EventsJoin me this fall in Europe (and San Francisco):Zurich - 1 day Lean UX in the Enterprise Workshop - August 30, 2017 (part of FrontEnd Conference)San Francisco - [NEW WORKSHOP] 2 Day Business Agility: Digital Transformation and Product Innovation at Scale with Barry O’Reilly - October 19-20, 2017 (early bird ends Aug 31)Manchester UK - Lean UX in the Enterprise 1 Day Workshop, part of NUX - October 25, 2017 (early bird seats nearly sold out)London - 2 Day Certified Scrum Product Owner Course with Jeff Patton - November 13-14, 2017 (2 seats left here)Berlin - 2 Day Certified Scrum Product Owner Course with Jeff Patton - November 15-16, 2017 (60% sold out, early bird ends Aug 31)———————————————————————————————

As always, if you want me to work directly with your company on training, coaching or workshops on the topics of organizational agility, digital transformation, product discovery and agile leadership, don’t hesitate to reach out. Like this newsletter? Forward it to a friend. Don't forget, you can now hire me for short, remote consultations 30 minutes at a time. Get started by picking a time here that works for you.