Tl;dr:
This article describes the continuous product improvement cycle: the foundational model I use in teaching product development. The article describes why products continuously improve and why there’s an expectation that tech products improve faster. The article breaks down the 4 basic parts of the cycle:
- Sense: the work we do to understand our customers, our market, our technology, and how people use our product today
- Focus: how we use vision, strategy, and target outcomes to prioritize what we work on
- Discover: the work we do to analyze, design, and test our ideas before we fully invest in building them
- Deliver: the work we do to build and release new products, features, and capabilities at scale to our customers – the stuff that really improves our product
If all that seems obvious to you you can skip this article, or come back and read the details when you need it. Otherwise, read on.
Make sure you understand the basics
Before you get too far in this article, make sure you have a good grasp on what I mean by “product” and by product thinking. Be clear about the differences between output, outcome, and impact, as well as customer needs and business needs. You could watch this short video or read this on the tension in product thinking and and this on why we tend to think our product ideas will often work when they usually won’t.
If you’re clear on what a product is, that leads us to our next challenge: tech products are different from traditional packaged products.
Tech Products are different
When you think of a product chances are you’ll think of something physical; something you can touch; something you might have bought in a store or online. Like all products these physical products were built to solve a customer’s problem or fulfill a need – and the successful products get used to do just that. The companies that make these products work hard to innovate and improve these products. And, when they do, they will retire the product you’re using and replace it with a new one. It could be the same named product with a “2.0” label, or a completely new product. Either way, traditional products improve themselves using an obsolescence model. The old product is made obsolete by the new product.
Software products are different. Since we’ve had ubiquitous internet and cloud computing, most software companies have quit re-releasing new products and now continuously improve the products they have in the market. You’ve probably noticed there is no new version of Spotify, Zoom, or Microsoft Word coming. Instead these products continuously improve themselves by adding and removing features and capabilities. And, they do this at an ever increasing rate. So, while all products continuously improve, software products improve more frequently and with smaller changes than traditional products.
As tech product consumers we’ve come to expect our products to continuously improve without having to replace or rebuy them. And, if they stop improving, chances are we can find a better alternative.
I’ll use the term tech product to describe any product where software is a substantial part of that product. This likely includes your car, your phone, your home network equipment, or your robotic vacuum cleaner. While these products are physical, they’re loaded with firmware and software that can and usually does change frequently. If you own an iPhone you know how often apps release new versions and how often Apple releases improvements to the operating system. If you drive a Tesla, you know how often new software updates are downloaded to your car and the Tesla app used with it.
In 2011 Mark Andreeson wrote an article in the Wall Street Journal titled Why Software Is Eating The World. In it he said that in the future “anything that can be software will be software.” In 2011 that may have seemed like a bold prediction. Today it seems rather conservative. We all use more software products than ever before. Software infects more of our physical products than ever before. And, today more than ever we expect those products to continuously improve faster and faster. And, all that has big implications on how we see product design, development and improvement.
The continuous product improvement cycle
I help companies adopt a product-centric way of thinking and working. One of the first things I do when I sit down with an organization is to evaluate the way they work today. If we’re going to improve things together, we need to understand where to start. Most companies tend to believe they need help building and changing products faster. They believe their biggest challenge is in turning their great ideas into product changes fast enough. But, once they understand the whole continuous improvement cycle, they usually see they’ve got bigger problems to solve elsewhere.
The model looks like this.
Yes, all my models tend to be a tangled mess. This one is no exception. But, it’s not as complicated as it looks. It has four simple parts: Sense, Focus, Discover, and Deliver. In this model I’m not proposing a new process or a new way of working. This is the way your organization currently works – even though it likely doesn’t use this language to talk about it. The question isn’t “do you do this?”, but “how well do you do it?”
Your organization already works this way. The question isn’t “do you do this?”, but “how well do you do it?”
So, let’s step through the model.
Place products, customers and users at the center
Every company makes products. They exchange those products for money that helps the organization sustain itself and grow.
It can be a challenge for organizations to identify their products. For example a bank usually recognizes its end products as different kinds of financial products: checking and savings accounts, credit cards, and loans for example. That may be obvious. But, when you break down the experience of a large product, inside you’ll find smaller component products. Just like if you were to take apart your car, you’d find it was composed of many different products used to assemble it.
Break down product experience to identify its component tech products.
End products are the things your organization sells. If your organization has a website, those are the things it describes there.
Customer enabling products are the things that allow customers to interact with your organization and the different products they own. For a bank this includes things like the bank’s mobile app or its website. You don’t buy the bank’s mobile app, rather you use it to interact with the services you do consume from the bank.
Employee enabling products are the things that allow your employees to support end customers and to do their jobs more efficiently and effectively. For a bank this includes the applications running in call centers or in bank branches.
Product team enabling products are the technical services and tools that help other tech product teams move faster. For example in a bank the mobile app teams and call center teams must both have functionality to authenticate customers, see what types of accounts they have, and allow them to make payments or changes. Rather than every team rebuilding the same functionality, product team enabling products are shared services that allow engineers from the customer and employee enabling teams to build and support their applications faster.
Partner enabling products are the tools that help partner companies develop their own solutions leveraging your organization’s products. For example the salesforce platform enables thousands of partners to create applications based on the salesforce platform. Most banks publish partner enabling APIs to allow accounting tools to get at customer account information. This is why your personal accounting software can see your bank balance and transactions.
Each product type has its own unique customers and users.
Every product team must start by understanding what their product is, who their customers are, the value proposition customers get, who they users are, and what users do in order to get that value proposition.
Sense: Continuously Listen and Learn
The story starts by simply paying attention. If you have a product out there in the world, there are customers choosing it and using it. Pay attention to that.
Tactical sensing focuses on what customers and users do today
You’ll do this by interviewing and observing customers. You’ll do this using product metrics that show who’s using your product, what they’re doing with it, and where they might be struggling.
Your organization likely has other sources for learning about customer’s behavior today. Things like:
- Customer service or support
- Reviews and social media mentions
- Professional services
- Industry trade shows
- Customer satisfaction surveys
- Customer advisory boards
Likely lots of others.
It’s paying attention to what customers and users do today that helps you identify customer’s problems and unmet needs.
One of the simplest practices I recommend to all teams is to pay attention to actual effort and outcome using a simple visualization. This is tactical sensing.
Strategic sensing focuses on the customers you don’t yet have
For your organization to grow it must acquire more customers. And, you’ll need to tune into the customers whose problems you don’t yet solve, the customers that looked at your product but didn’t choose to use it, or the customers that tried the product but then abandoned it. Strategic sensing often takes the form of market research or studies that look at the needs and behavior of people that aren’t your customers today.
To grow your product you’ll need to identify problems and unmet needs for the customers you don’t have.
Technical sensing focuses on the technology your product is built on
If you’re building a product that’s primarily software, you know that the way we develop software continuously changes and improves. You’ll need to continuously change and improve your underlying technology. And, you also know that the sensible decisions you made at the time you released the product are now referred to as technical debt today.
Technical people must continuously evaluate your underlying technology and pay continuous attention to emerging technical options that could and should be incorporated into your product.
All of this sensing will expose lots of problems and unmet needs. I’ll use the euphemism “opportunities” for these things. And, I can guarantee that your organization is buried under a mountain of these, even if it’s not very deliberate about sensing. This leaves your organization with a focus problem.
Focus
Your organization will be buried under a mountain of problems to solve, both business and customer problems, as well as ideas to solve them. We use focusing practices to give us tools to solve them.
Use Vision and Strategy to focus on long term outcomes
Your vision ideally tells the story about how you imagine customers using your product years into the future. Your strategy ideally lays out the steps your organization is taking to move towards that future vision. Both vision and strategy ideally focus on the customer behavior you hope to observe, the outcomes, that helps your company to sustain itself and grow.
Opportunities aligned with vision and strategy deserve more focus.
Use Target Outcomes to focus on specific outcomes you’re pursuing right now
A target outcome describes the specific customer need and the observable changes in customer behavior you’re targeting.
Outcomes aren’t the features you’re focusing on building. They supply the criteria you’ll need for choosing specific features to focus on, and a way to measure success.
I like using product centric objectives and key results, OKRs, to package up target outcomes. You might have a target outcome that’s focused on your next strategic move, a current technical challenge, or a current customer challenge,
Budget time to spread focus across equal priorities
If you’re responsible for the continuous improvement of a product you’ll need to focus on strategic change – acquiring more customers to grow the product, tactical change – improving or repairing the experience for current customers, and technical change – updating and improving the underlying technology. These things are equally important. Product teams must budget time to do all these things at least every quarter.
For example, if you were to treat yourself as a product, you’ll need to get a good night’s sleep, eat healthy meals, and get some exercise ideally every day. These things are equally important. We don’t sleep at the end of the day because it’s low priority. We often neglect exercise because it doesn’t seem urgent. But, we know we’ll pay the price with health problems later if we don’t start to prioritize it. Ideally we budget time to do these three things every day. How much time and when is up to us.
It’s up to teams to budget a percentage of their time on strategic, tactical, and technical change every quarter. Neglect any of these things and your product, customers, users, and your organization will eventually pay the price.
Your organization may have even more categories to budget for. For example banks must budget time for addressing regulatory changes. We often can’t predict exactly what’s coming, especially for tactical improvements. We usually don’t know months ahead about the challenges or opportunities customers have today. But, we know there will be plenty. They’re predictably unpredictable. Budget time to address them.
Discover
Given some outcome you’re focused on achieving, now we can really prioritize the options that will help us achieve those outcomes. By “options” I just mean the feature and capability ideas you’ll add to your product. And, I promise you’ll have no shortage of ideas. Everyone, including you, has them.
We use discovery work to be deliberate about considering many ideas. We use discovery work to do analysis and design. We use discovery work to test our ideas before we fully invest in building them.
Consider many ideas
Considering many ideas is often referred to as ideation. We do this because we can usually guarantee that our first ideas are never our best. Great ideas seem obvious in hindsight, but not always in foresight.
Most of our ideas won’t succeed
Most new tech products fail. We all know the failure rate of tech startups is high. Most features or capabilities we put into products are rarely or never used. Pendo, a successful creator of cloud-based product analytics tools said in 2019 “Based on an aggregation of anonymized product usage data, Pendo determined that 80 percent of features in the average software product are rarely or never used.”
The odds of an idea getting the successful outcome you’re hoping for aren’t great. It’ll take some work to find and iterate the idea to great.
Analyze, design, and test
You’ll need analysis to make sense of the world as it is today. To research, understand, and make sense of customers’ problems and needs. You’ll need to design, imagine the world differently to visualize your solution and think through the technical aspects of building it. And given that most of our ideas are packed full of risks that might bring them down, you’ll need to test your beliefs about your idea. We do this using a process called validated learning.
Given our idea we expose our beliefs about who our customers and users are and their needs. We expose our beliefs about what they’ll do with our solution when they see it, the outcomes, and how we’ll measure those outcomes. We expose our beliefs about how current customer behavior today isn’t good for our business, and how good customer outcomes wil help our business. And finally we expose our beliefs about how and how long it might take to build a solution. I like using an opportunity canvas to do that. That’s a lot of beliefs. And, if you’re honest with yourself, you’ll be less than confident about some of them.
We deal with that lack of confidence with a simple two step process. Given a belief we’re not so confident about we ask:
- What would we need to learn to be confident that we’re right?
- What’s the fastest way to learn this?
The fastest way to learn this is usually a learning activity. A test. What we get out of that test is information that helps us improve our idea, or sometimes kill it and move to a different idea – to pivot. I use this simple worksheet for exposing your hypothesis and finding your next best test
The heartbeat of product discovery, the validated learning loop, is making sense of what we understand, exposing risks and building a test, testing, and then making sense of what we’ve learned.
This is what Lean Startup referred to as the build-measure-learn loop. But, I draw it like this.
When you’re as confident as you can be that you’re building something that’ll get your organization the outcomes and impact you expect, it’s time to build and release your product improvement.
Deliver
We use discovery to remove as much risk as we can from our ideas. We use delivery to build our ideas as fast, as predictably, and at as high quality as we can. We’re investing more time and money to build our solutions at scale than any other activity. So, we continuously scrutinize those things that matter in every project: time, cost, scope, and quality.
This is where common agile practices like Scrum are very useful. Using a process like Scrum we work in short time boxes, a sprint, usually a couple weeks. We fix cost during those two weeks by fixing team size – since in software development most of the cost comes from the people hours it takes to build it. And, teams agree on and fix scope at the beginning of every timebox. At the end of the timebox we measure how much work we actually did, our velocity, and we learn just how fast and predictable we were. At the end of every timebox we demonstrate our product and review its quality. Then we fine tune our delivery process to continuously improve our speed, predictability, and quality.
During delivery we focus on speed, predictability, and quality.
Everything, everywhere, all at once
This is not a linear flow. An organization and a product team will be working in all areas at the same time.
You’ll be sensing continuously to pay attention to your current product, customers and the market.
You’ll constantly reconsider where you should be placing your focus, shifting vision, strategy, and the objectives you’re focusing on now.
You’ll be constantly doing discovery work – analyzing, designing, and testing ideas before you fully invest in building them at scale.
And, I’m sure you feel intense pressure to deliver more features and capabilities faster.
If you’re with a small organization, this 4-part model is your process. As your organization grows you’ll find that responsibility shifts right. Leadership takes more responsibility for vision, strategy, and goal setting. Research and tech leadership take more responsibility for strategic research and architectural improvement. This leaves teams spending lots of time balancing discovery and delivery work. In agile development that’s commonly called dual-track development.
There more…
I use this model to help me and the organizations I work with make sense of product development. Each area takes different types of thinking and practices to support it. Evaluating how strong you are in each area helps give you a starting point to improve the way you work.
Friends I talk with that come from a stronger marketing background warn me that I’ve not paid enough attention to marketing and communication. I try to suggest that’s part of focus and strategy, as well as part of delivery. But, it’s messy. I’m not even sure I believe myself when I say that.
There’s also overlap. In the context of teaching product thinking and release strategies I’ll draw a big distinction between a release to earn and a release to learn. Both types of releases go out to customers and rely on the delivery part of the model, but a release to learn goes to a small subset of customers and while we use delivery practices, we’re doing it as part of discovery work.
If you buy the essential thinking behind this and believe that all products must continuously improve to succeed and sustain your organization, then ask yourself how fast must you improve to be competitive?
How fast must your products evolve and improve to be competitive?
Now what?
I’ll follow this article with one that gives more details on evaluating your product development cycle. Stay tuned.
If you’ve got comments or suggestions, try me on twitter or linkedin. But, honestly I can be pretty crappy at social media, so always feel free to reach out directly via email.
And, if you’d like to go deeper into this model and the practices that support it, consider taking a class from me.