Shift From “Product First” to “Product Last”
Once upon a time, “product first” was supposed to be about how to best deliver products and features to best serve customers. After all, if we’re not serving customers well, what are we doing? We need to win customers, make them happy, retain them, and create growth for our company. This is done through great products and services that meet or exceed target audiences’ needs.
I’m not sure why someone called this “product first.” We’re putting the customer and their needs first. We should have just called it “user-centered” or “customer-centric.” That would have helped us stay focused on product-market fit and customer satisfaction. But…
Over time, the definition of “product first” evolved — or devolved — to mean absolutely putting the product first.
We start with an idea, feature, or solution. We hope it’ll work out for customers, but the focus is the product. We’d rather start with trying to prove our idea is good than to better understand users’ tasks and needs. We think this will be fast.
Product first is often business first.
We typically start with business goals and what the business hopes or needs to achieve. We have product management books and authors reminding us that we have to put what the business wants first or else we’ll go out of business.
The business wants to make money and keep making more of it while cutting costs. We know this. I think of business goals as the tonic pedal, a single note playing underneath the rest of the music. Or perhaps it’s a cloud always hanging over us.
Our process often starts with a feature, a piece of the product. We might say it’s a “hypothesis” or “solution.”
Over time, we’ve moved further and further away from focusing on product as how we deliver value to our customers.
We fell so in love with product that we forgot that product doesn’t exist to push customers around a chessboard and make execs happy. Our products and services are all we have, and their main job is to win, satisfy, and retain customers. If we are not doing those well, we are failing.
We claim that we want to deliver value and satisfy customers, but how do we follow through on that? How is that baked into our processes? Are we driven more by deadlines or by quality? Are we counting how many features or fixes we release, and not considering how users perceive their quality or value?
Do we say, “Outcomes over outputs,” and then celebrate one or both being low quality or failures? Is anyone truly held accountable for poor outcomes, failures, and bad decisions? If we celebrate or glorify failures, does that mean we see outcomes as good even when we have failed?
And which outcomes do we care about? Business goals and objectives? Or do we also measure success from customers’ perspectives? Customers don’t care about “converting more” or “higher average order value.” Which outcomes are we measuring that resemble how our customers will measure or judge our product or company?
“I truly hope this product feature better helps me convert to a paying customer,” said no website visitor ever.
What were people trying to do? Were they trying to accomplish that task faster, more easily, cheaper, with greater accuracy or no errors, or without needing to contact Support for help? Did we facilitate that?
Can we measure what we improved for users? Can we measure what we made worse? These are the true outcomes. Signals of customer and user success are signals of business success.
Product is an output. We are product last.
“Product” should be a strategic and tactical process through which we create something valuable, desirable, accessible, and hey, it’s what I need and it just works. If you’re lucky, it’ll be innovative. But considering how badly companies do “the basics,” I’ll settle for not innovative at all but it’s great for how I need to accomplish my task.
Don’t start with product, features, ideas, or hypotheses. Start with a good understanding of target audiences’ tasks, experiences, and pain points. Be solution-agnostic early in your process. Avoid the feature factory and order taking.
Maybe the well-understood problem is solved through product. Maybe it should be solved through a service. Maybe both. But we can’t understand users’ problems and their root causes without good research executed with good rigor.
At the end of that process is our product. We are product last.
Product first should be customer first, but is too often a feature factory of order takers.
Product first is too often empathy theater, pretending that we really care about our users while treating them as pawns.
Product first is too often a guessing lasagna of misguided or ego-driven experiments, making paying customers guinea pigs as we quickly push out minimum viable frequent failures.
Product first is innovation theater. We say “innovation” constantly, but what have we innovated or invented? What have we disrupted? More importantly, are we getting the basics right? Are we so great that customers never complain about the simple stuff?
Product first doesn’t mean you have product-market fit for your next big idea. Your concept, hypothesis, or solution-looking-for-a-problem might be a poor fit for your experience ecosystem or the market.
Product first isn’t necessarily Lean. Lean is about examining processes, outputs, and outcomes; and trimming the “fat” of risk, waste, defects, bugs, and low value crap. If we are seeing failures, poor decisions, poor process, poor outcomes, and “we’ll fix it later,” we’re not Lean.
Product first might not be Agile. Maybe you do it in “sprints,” but the core of Agile is consistently delivering quality on a reproducible cadence. It’s not about going the fastest we can. It’s about being efficient: balancing velocity with quality and successful outcomes. If you have speed but low quality or poor outcomes, congratulations on your speed, but you don’t really have efficiency. A factory floor spitting out defects is inefficient.
Here’s my customer-centric “product last” process, similar to how I presented it in chapter 20 of my “Customers Know You Suck” book (but only now am I describing it as “product last”):
Phase 1: Understanding
Phase 1 isn’t a hypothesis that “users need this” or “we’ll increase conversion rates if we try this.” It’s not “does anybody like my idea” or “can I validate that something is the way I think it is.”
Phase 1 is really understanding what’s going on here. Context. Human experiences. Technology. What are people trying to do, how do they do it now, what’s working well, and room for improvement. Tasks, habits, needs, and real problems. We learn these through observation first and conversations second. We are unlikely to learn this through a survey or by asking people what they need. Sometimes they don’t understand their own problem or know what would best solve it.
We claim to value research and learning. So let’s have specialized Researchers answer our open questions, and change opinions, guesses, and assumptions into evidence, data, and knowledge. Define the root causes.
Recommended by LinkedIn
We’re solution-agnostic at this phase. We’re not exploring or testing features or ideas. We’re not checking if people imagine that they might be interested in a thing we could build that they can’t see or experience now.
Phase 2a: Problem Statements
After this generative qualitative research, Researchers will write up problem statements (among other artifacts and documents): real problem statements based on real current customers and target audiences, not something we’ve invented, hoped, or tried to reverse engineer.
Thanks to Phase 1, we know where people have frustration, confusion, disappointment, distraction, inefficiency, anger, a knowledge gap, and dead ends. We can tell the difference between symptoms or consequences and the root causes underneath them.
We don’t have a product yet. We shouldn’t have a list of features. We’re still solution-agnostic.
Phase 2b: Prioritization of Problem Statements
Instead of which feature should we do first, we prioritize problem statements. Which problems should we handle first? Why?
This is a cross-functional team discussion and decision. This isn’t owned or controlled by one role.
Prioritization is normally determined based on three factors: business value, target audience value, and tech/Engineering. Typically, a representative from each of these areas scores problem statements for how high a priority each problem is. These scores combine to give a final score, though discussions might cause something else to rise to the top of the list or sink lower.
Phases 1 and 2 are more customer-centric. Phase 2b brings the voice of the business back into conversations. Here is where we start balancing the two realms: business and what I call your experience ecosystem: potential users, current customers, procurement roles, resellers, installers, maintainers, third parties, etc.
Phase 3a: Strategy
Given what we know about people, contexts, systems, tasks, and problem statements — and knowing that the business expects to generate revenue and achieve other results — what’s our strategy? What is our carefully crafted plan to make all of this happen? How will we make this happen efficiently with the least risk and the least waste?
Our strategic path to business success requires us to take the people in our experience ecosystem on a path to success. We can only do that when we understand their tasks, needs, and habits.
We need an overarching CX strategy. Some would say that we need a product strategy, but what if the answers aren’t “product”? What if they are services, experiences, human interactions, physical products, or something else? Not everything is best solved with a digital product.
Our CX strategy is the strategic approach for how one or more projects will achieve a set of goals we have laid out for our company as well as the tasks everyone in our experience ecosystem is trying to achieve.
Phase 3b: Planning
Now that we have priorities and our overarching strategy, your CX/UX teams and workers should be able to estimate their work, and create a plan or roadmap. Given the problems we plan to solve, how much time will they need to do their work well? Do they need more headcount, tools, or other resources? This is where we budget for what it takes to do more of the Human-Centered Design process well.
It’s a bit early for Engineers to estimate. We have no idea what the solutions or designs will be. Engineers will need to estimate and plan later.
Phase 3c: Potential Solutions
We started our “product last” process without pre-deciding the solution or the features. We were solution-agnostic until we had enough evidence, data, and knowledge to consider what would best solve experience ecosystem problems and deliver value and quality.
Now we are ready to consider solutions. Note that solutions and features aren’t the same thing. A potential solution is something that we believe will satisfy our balanced user and business goals. There are multiple possible solutions. The solution we eventually select as the best will be broken into features.
These potential solutions can be modeled and tested. This is part of the Human-Centered Design process, and executed by CX and UX professionals. We don’t test for “do they like it,” “how do they feel about it,” “how often will they use it,” or, “what will they pay for it.”
We test for:
Once our designs or prototypes are tested, and professional Researchers have verified good usability and that the execution and idea solve real user problems, now we have a product. It’s at the end of a product development, or more accurately, an R&D (Research and Design/Development) process.
We are product last. We are experience ecosystem first.
We avoided the typical cycle of throw-it-at-the-dartboard-and-pray experiments. We avoided the guessing lasagna: guessing why people do or don’t do things, layering on guesses of what they need or want, and more guesses around what would best solve that.
We have a solution made up of features and functionalities. But we’re not the feature factory. We didn’t go with solution first, guess first, or product first. We put more strategy and critical thinking into the process. We are more likely to be successful. We worked smarter, even if it took a little longer. That time investment will pay off in value, quality, and saving us from having to clean up our own messes later.
We have an assembly line and various specialized workers, but we didn’t have a product until the end.
We are experience ecosystem first because that is the path to achieving business goals in the short and long term.
We measure outcomes beyond did the business get the conversion rate it was hoping for. We measure experiences.
Shift your language and your processes. We are product last. It’s the output of the process. Build quality in. Prioritize quality as much as your customers and users do.
Connect with us or learn more:
Continuous Improver
7moAnd here I was thinking that you start with the market.
Service Designer | System Thinking | Facilitating Innovation | Community Builder @SDD India | NID
8moPutting people first and products last is a powerful shift in mindset. It is sad that one needs to be reminded - to prioritize understanding customers and delivering quality over chasing features and deadlines. Valuable perspective, Debbie.
Product Design Strategy & Leadership
8mo10000%. Product has come to mean “let me try anything and let a/b tests and analytics decide what has value” I’m excited to see more and more people saying value (quality) matters first. It’s time for that scale to rebalance back towards quality and transformative work over quantity of incremental trials without grounding in value.
Founder Etch Group * If you want to go fast, go alone. If you want to go far, go together. African proverb.
8moGreat post - “We fell so in love with product that we forgot that product doesn’t exist to push customers around a chessboard and make execs happy.”