This is the first in a series of articles diving into the product operating model, its impact on an organization and how you can get started. Subscribe here to get notified when the next article is live.
The Uncomfortable Truth
For many organizations, time, scope, and budget have been the standard for measuring success of software delivery projects. Teams are tasked to build what sounds like a promising idea for an agreed upon amount and by an agreed upon date. And when they do, everyone feels good, they celebrate the accomplishment, and move on to the next big thing.
But what happens when those things we build don’t actually help our customers? Is it possible to meet time, scope, and budget – and yet fail in the eyes of our customers?
Much has been written and said about idea failure rate. Respected thought leaders like Marty Cagan would suggest upwards of 80% of ideas fail to generate positive return on investment. Similarly, some of the biggest and most successful companies on the planet, such as Google and Microsoft, have conducted studies to find that as few as one-third of their launched ideas actually generated positive results. If these statistics are even remotely accurate, how does your company stack up? Let’s take a closer look…
Take a moment to think about a handful of solutions your company recently launched. What feedback have your customers since shared? Has the adoption rate been what you projected? Have you iterated on the solution following the initial launch? Did it solve the most important problem for your customer?
Meeting the expectations of time, scope, and budget is in fact how many (many) organizations traditionally measure software success. This is characteristic of organizations that operate with a project mindset. If your organization approaches software development in this manner, it may be time to reflect not only on how you measure success but, more importantly, if the software you are building is actually helping you create a competitive advantage for your business.
Building for Impact
In the digital age, every industry is being reshaped by software. Marc Andreesen famously talked about software eating the world more than a decade ago, and it’s safe to say that still rings true today. Organizations that embrace software to automate processes, create a better experience for their customers, and reimagine their business will create opportunities to differentiate and prosper. To seize precious opportunities and fully realize the impact software can have on your business, you can’t afford to repeatedly miss with your ideas.
To deliver meaningful value to your customers, you must begin to ask some deeper questions:
Before asking how long will it take or when will it be done…. Consider asking what makes this a problem worth solving?
Before asking how will we build it…. Consider asking how the customer might value the solution and what will make our solution different from our competitors?
Before asking who is going to build it…. Consider asking what does better look like for our customer and how will we know if we have solved their problem?
The Agile Manifesto was crafted in 2001 by a group of thought leaders seeking an alternative to documentation- and process-heavy software development. The manifesto was grounded in 12 principles. While the manifesto generally describes a better approach for software delivery, the first principle is equally important to modern product development:
Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.
If our highest priority is truly to satisfy our customers with valuable software, building with a project mindset simply does not do enough to address the value part of the equation. Your organization must also learn how to build with a product mindset.
Building the right thing with a product mindset requires a deep understanding of customer problems, wants, and unmet needs. This understanding ensures we are solving the most valuable problems for our customers. It also opens up the space to innovate and explore multiple solution alternatives. Sure, building software in a timely and cost-effective manner is important – but when we operate with a product mindset, we can avoid the expense of building something of little/no value and instead build something our customers will actually use.
Why It Matters
Hopefully, the differences between Project Mindset and Product Mindset are now more clear. If you’ve wondered how some organizations are winning with software, you’ll likely find they have learned how to build the right thing rapidly with a high degree of quality. Your organization can be equally successful – but it starts with a better understanding of how to build for impact.
Why It Matters
Success = Time + Scope + Budget
Success = Customer Value
Building software that customers don’t value is an expensive lesson
Goal = Produce Outputs
Goal = Influence Outcomes
If you help your customer, they will return the favor (ex: revenue)
Love = Our Ideas
Love = Customer Needs
If we understand their needs, we can build for impact
How = Building Our Idea
How = Validating Our Idea
Building quickly and with quality is important – but only after we have evidence it will solve the problem
So it comes down to this: if we build a piece of software, but it doesn’t influence what actions our customers take, or the things they say about their experience, or the way they feel about doing business with us, what have we really accomplished? Our ultimate goal with software development should not be to see how much we can produce – after all, what customer has ever told us they appreciate that our software met time, scope, and budget? If we learn how to operate with a product mindset, we can maximize customer value and deliver impactful business results.
Now that you’ve solidified your understanding of product mindset and why it matters, you might be ready to try it in your organization. Sounds easy but changing how your team or your company approaches software development can be an uphill battle. In our next article, we will provide some ammunition for overcoming decision-maker objections and provide some simple, practical suggestions for how to get started with modern product development in your organization.