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.
Watch this article as a video where I also took questions from people who attended live.
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.”
- Sometimes it’s a solution to a problem that’s not well understood. We’re sure we really know our customers, so we didn’t bother researching people, tasks, or their decisions.
- Sometimes the problem doesn’t exist. We reverse engineer use cases hoping someone might have some reason to use this thing we came up with.
- Sometimes it’s a stakeholder-centric solution; this is what a leader or stakeholder wants us to do for their own good or bad reasons.
- Sometimes we call customers and ask what features they need. We forget that most people think in terms of their tasks and making them efficient and accurate. Our target audiences might be open to any feature that achieves that. They might not be able to envision or invent the feature that would serve them best. But we’re focused on the product, so we ask them about the product, our ideas, and what do you think of this mockup?
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.
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:
- Does it solve the original problem statement?
- Does it solve it well?
- Did it create any new problems?
- Is this the right execution of the right idea? Or do we need to go with a different execution… or a completely different idea or solution?
- Where is there room for improvement?
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.
- Does the task take less time while also being less error-prone?
- Are users seeing increased efficiency or accuracy?
- Does this system work well for their tasks, habits, perspectives, decision-making, and styles?
- Are our target audiences complaining? Returning products or ending contracts?
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:
- CustomerCentricity.com — our website
- youtube.com/@cx-cc — YouTube channel
- patreon.com/cxcc — online community and free mailing list
- Articles on Medium or LinkedIn
- cxcc.to/ckys — “Customers Know You Suck,” my recent book on improving customer adoption, satisfaction, and retention
