While I’ve put it together so (I think) it makes sense on its own, this page’s main job is to serve as a general reference for learners in my online (Coursera) courses on Continuous Delivery and Hypothesis-Driven Development. After reading this page, you will be able to:
- Explain how agile teams can structure their overall flow around a product pipeline
- Identify the relevance and tools associated with each step on said pipeline
- Facilitate discussions about where a team should invest its time on improving its execution and how they’ll know if those investments are working.
A generalized product pipeline looks something like this:
The items you see in black below each major area (Continuous Design, Agile Dev., and Continuous Delivery) are the metrics I recommend you use to assess them. I find the concept helps teams think about the relationship between what everyone does and the outcomes they should be driving for their company. The following sections describe practices and tools teams can use to improve each area.
Just to forewarn you, this is where I spend a lot of my time on making stuff, teaching, and advising companies. I think it’s pretty important because if you don’t do this well, you ‘ll waste lots of energy, time, and money on building things no one wants. Here are a few extreme(ly funny) examples: 13 New Inventions That No One Asked For. With all due gravity, though, I see lots of smart, capable teams burn themselves out by doing a great job of building a great app that no one wants. Pretty much my reason f0r being here on the Internet is to help you avoid that.
Venture Design is the framework I use to help teams unpack how to do this and make good decisions about where to invest their precious resources. How do you know if it’s working? I think all teams should always been looking at the proportion of features (release content) that seems high engagement vs. doesn’t. If you haven’t killed at least 20% of your new features, you may have a problem. No one gets it right all the time.
Let’s look at a few big subsections of this in more detail.
Few teams spend enough time here. If you don’t believe me (and you probably shouldn’t right off the mark), here’s a great piece where a veteran product manager talks about his experiences across Google, Facebook, and Intercom: Great PMs don’t spend their time on solutions.
Most ideas are bad. The success rate of new products is something like 1/10. The success rate on new ideas is probably on the order of 1/1,000. If you want to take your ideas from (likely) bad to good, and foster a high-functioning practice of agile, I recommend you do these three things:
1. Test Your Ideas on Who? and What?
If your solution is for someone you can’t imagine and a need you haven’t observed, I’d pause and fix that. There’s a well established body of work on testing customer personas and problem scenarios (aka jobs-to-be-done). For a quick reference, you may like:
Problem Scenarios Tutorial
Discovery & Testing Tutorial
Template for the Above
I also teach this material in the online course Agile Meets Design Thinking, which I can’t help but recommend.
2. Test Your Solutions before You Build Them
This is basically what Lean Startup is about: a domain-specific extension of agile for testing solutions, pre-build. It uses an evidence-based (aka ‘science’) process to test new ideas. The promise isn’t that all your ideas will work, but rather than you’ll minimize the waste of building something no one wants. It works. There’s more about it at the link above and in the same template you saw in the previous item.
If you want something more full bodied, it’s also a centerpiece of my online course Hypothesis-Driven Development.
3. Don’t Start Building Things Yet
You’ll know none of this is working if that’s what you do. Don’t- please, really. Most ideas aren’t meant to be, but many teams are. Invest the time to make sure you’re committing your team to something that matters to someone.