How to Escape the Delivery Trap (and Find Time for Discovery)
A guide to designing customer-centric products that balance product discovery with product delivery
Reading time: 21 minutes
You got hired on a product team, but something doesn't feel right.
There's never enough time to talk to customers. Instead of designing customer-centric products, you deliver screens for an endless backlog arbitrarily chosen by management.
As time goes on, you get pushed further toward the end of projects. The list of "required" screens grows as the deadlines get shorter.
You wonder if you only have a job because you know Figma and your manager doesn't. You feel under-challenged and overworked. What's happening here?
You, my friend, are stuck in the “Delivery Trap.”
[concept inspired by Anthony Sciamanna and Melissa Perri]
Build traps, feature factories, and pixel pushers
What is the Delivery Trap? It has many names.
When product design is judged by visuals and speed, that’s the Delivery Trap.
The worst part about the Delivery Trap, is that you may be rewarded for it in organizations with low design maturity.
If you can make pretty stuff fast, you may move up the ranks, but the true value of your work is not just delivering value to management…it’s in your ability to deliver value to the customer.
If your customers need more than visuals, you’re trapped between expectations at work and expectations from the customer.
The Delivery Trap is a concept with many aliases:
Feature Factory - a product team focused on delivering features rather than value
Build Trap - a product team focused on outputs rather than outcomes
Wireframe Monkey - when designers are uninspired and design anything for anyone
Pixel Pusher - when management takes over the design process and pushes design ideas
“Norman’s Law: The day the product team is announced, it is behind schedule and over its budget.”
Companies that put design in the Delivery Trap, appreciate design for the artifacts that it produces, not the problems it solves. They understand design from a UI level, but not the UX level.
These companies think that design is only a delivery phase, especially common in the agency world.
These companies may sell you on the idea of user-centered design but when the job starts, it's all about visuals and output...not customer outcomes.
Design should never be a phase of a project. It should be integral to the whole project.
Design isn't gold plating you can add to the end of a project. Design isn’t a workshop you can run with your team.
It's an end-to-end process that turns customer insights into valuable experiences.
How Product Discovery can help
You need to do product discovery, not just product delivery.
If you're a UX or a product designer, you cannot do your job if you're stuck in the delivery phase.
You need to start at the beginning and discover problems with the customer. But how do you communicate that?
The duality of discovery and delivery is a way to communicate the need for more than delivering features.
[a framework for product discovery, image from What is Product Discovery? by Jeff Humble]
When companies get stuck in the Delivery Trap, they try to optimize the time of their designers and developers by squeezing more work out of them. They try to separate the decision-making from the building team.
They don’t realize that the solution team works much better if they also understand the problem they’re trying to solve.
Why Product Discovery is important
Product discovery is crucial to becoming a design leader. Product discovery helps you ensure you’re designing the right thing, while delivery helps you design the thing right.
It’s possible to be designing the wrong thing exceptionally well. Many designers think they’re polishing a precious rock until they show it to someone and realize they’ve been polishing poop, not a diamond.
“A brilliant solution to the wrong problem can be worse than no solution at all: solve the correct problem.”
It can be very tough to share a design before it’s “ready.” If you’re a perfectionist, this can be downright painful. But if you want to work through those “shitty first drafts,” you must show early concepts.
Designers (especially UI and visual designers) are required to think about details. Naturally, we get pretty good at it. But that pixel-perfect lens can cause you to skip the big-picture discovery stuff and focus on details too early in the process.
If you’re detail-oriented, you might need to do conscious discovery more than the big-picture folks. If you’re already a big-picture thinker, you should make sure that you follow an accessible process where others can participate.
Using a classic design process like the Double Diamond, you can easily adapt it to a continuous product discovery process using the Zendesk Triple Diamond.
[a framework for product discovery, image from What is Product Discovery? by Jeff Humble]
Here are six ways to do product discovery in both the Problem Space and the Solution Space.
3 ways to do Product Discovery in the Problem Space
One of the easiest ways to communicate end-to-end design is to talk about the design work in two domains: problem work AND solution work.
Meme by Jeff Humble
This split makes it easier to communicate the non-obvious part of design: the problem work a.k.a. the UX stuff.
Problem work is all about exploring and understanding the problem from the customer's perspective.
The learnings from this type of work frame and shape the solution work that comes later.
Problem Discovery looks like this:
Uncovering existing data on the problem
Running research with customers to discover problems
Analyzing customer data to find root causes
Synthesizing research data to create a new understanding
Checking the company's assumptions about the customer's experience
Many of these activities will be more like research than design, and that can seem weird to non-designers. Problem work only hit the mainstream for design in the early 2000s so be patient with colleagues that don't get it yet.
“When companies do not understand their customers’ or users’ problems well, they cannot possibly define value for them.”
1. Make customer problems explicit.
One of the biggest reasons that companies forget about problem research is they skip the problem definition phase. Or perhaps upper management gets attached to a solution idea, and all they can see is confirmation that the solution must exist.
Meme by Jeff Humble
Product managers have one of the toughest jobs in tech because they’re stuck between business owners and the team.
Those crazy deadlines they’re putting on you probably come from their boss so cut them some slack. You can help by helping to define, check, and gather data for the problem involved.
By spending a bit of time on problem discovery, you can save everyone a ton of time in the end.
You don’t have to spend a lot of time on research. Even a bit of desk research using the front page of Google can be a big help at the beginning of a project.
Timelines and goals are key to getting research projects approved. Use the UX Research Canvas to make sure that your research is goal-focused and time-bound.
After you get a better idea of the problem involved, try to get the team to approve a simple problem statement. Framing a problem together is a great way to get the whole team on board before you move to solutions.
2. Take a continuous approach to research.
An emerging way to find time for problem work is Continuous UX Research, an always-on, weekly approach to research.
With Continuous UX Research, you’re doing just enough research to inform current projects. You want to keep the team up-to-date on what’s happening with customer problems.
In continuous research, you automate things like recruitment and timebox the research work in every sprint. Instead of long, drawn-out projects, you have weekly research rituals with your product team.
“In the university, professors make up artificial problems. In the real world, the problems do not come in nice, neat packages. They have to be discovered.”
But continuous research is a bit different than traditional UX research because it doesn’t get too far ahead of the product team. With agile product teams, you want “just-in-time” discovery and delivery.
Far horizon research that gets quarters ahead of the product team is best reserved for traditional UX research.
3. Democratize research on your team.
Meme by Jeff Humble
Democratizing research means you don’t have to do everything yourself. And bonus, you don’t have to present the research findings since everyone is up to speed!
With a bit of setup and clever timeboxing, you can get research down to a few hours a week.
This weekly problem discovery will help you build customer expertise like compounding interest and steeping the whole team in customer problems.
Solutions get better when the problem is understood correctly. Make time to explore those problems.
3 ways to do Product Discovery in the Solution Space
Non-designers usually get solution work, but even solution work can be misunderstood.
Solution Discovery Example Work:
Iterating on different ways to solve a problem
Testing different approaches with customers
Working with engineers to design feasible solutions
Running desirability and usability tests
Adapting solutions to fit the company's business model
Designing experiences that are usable and seamless
Iterating designs based on customer data
Experimenting with prototypes
1. Save details and aesthetics for the end.
Solution activities shouldn't include too much focus on how things look. If all you get is feedback about aesthetics, you might be stuck in the Delivery Trap.
Meme by Jeff Humble
Ironically, non-design stakeholders are often the ones that are overly focused on design details.
Keep your design work in the Solution Space as lo-fi and scrappy as possible so that design details don’t slow down your exploration. Instead of aesthetics, focus on functionality.
There are a million ways to solve a design problem, and you must quickly discover the best solution for your goals.
Don’t waste time on high-fidelity visuals until everything is finalized.
2. Every design can be a user test.
When you are focused on discovery, everything you release is a learning opportunity. It’s hard to know if you’re doing any good if you're releasing designs without measuring the effect.
Even a tiny change can be useful for learning when you’re actually checking it with users. The power of A/B Testing is based on the fact that you can learn a lot with a small change. But you don’t have to become a master at optimization to test your designs. You can learn through prototyping and concept tests, not just A/B tests.
One of the best ways to start testing is to make a prototype.
“A prototype is an early sample, model, or release of a product built to test a concept or process.”
Prototypes are a great way to test early concepts and get real user feedback before you release anything. With a little setup, a simple wireframe can turn become a behavioral experiment.
How to turn a wireframe into a behavioral experiment:
Ask yourself, “What is the riskiest assumption I’m making with this wireframe?”
Fill out an Experiment Card (includes prompts for assumption, hypothesis, and metrics)
Turn your wireframe into a clickable prototype
Find a few users to test your prototype
Shut up and observe the testers use your prototype
Record the results
Check the results against your Experiment Card
Adjust designs based on the results and move to the next experiment!
There are many ways to turn a design into an experiment. We think prototyping and testing assumptions is a powerful way for designers to get started in experiments. Experimentation is an exciting skill that can help you move into more strategic product work.
3. Release often, then move to v2.
Customers have a way of defying expectations. Product design would be easier if people behaved rationally, but that’s not the reality. Anytime we design things for messy humans out in the messy world, we are dealing with unpredictable outcomes.
It’s better to release sooner and iterate than cram perfection into a single release. Escape the Delivery Trap by pushing for an early-stage Minimum Viable Product (MVP) instead of a giant release.
Once the MVP is live, you can learn from actual customer behavior and improve the next update. Everything is an assumption until it’s in the hands of a customer. Don’t get too tied to any solution idea until you’ve got some real-world behavioral data to back the idea up.
By releasing in smaller, iterative cycles, you can avoid the squeeze of deadlines and feel more confident knowing you can learn from users before iterating.
Remember, people create deadlines, and they can be changed. That squeeze you feel is a lot bigger than you, so focus on doing your best.
Learning resources on Product Discovery
By now, you should have some strategies for getting more discovery into your workflow. If you work discovery into both problem and solution, you might escape the Delivery Trap.
Build discovery skills by learning research, experimentation, facilitation, and strategy skills. And try to replace some of that delivery work with discovery work…or find an organization that lets you do discovery.
Talks on Product Discovery
Watch this masterclass from Jeff Humble on how to get your team researching here
Watch Melissa Perri’s talk on the concept that inspired this article here
Watch Teresa Torres give an introduction to product discovery here
Watch this masterclass from Jeff Humble to learn how to experiment early here
This article is inspired by product leader Mellisa Perri and her “Build Trap” concept. I can highly recommend her book Escaping the Build Trap.
I also recommend books from Marty Cagan, Teresa Torres, Josh Seiden, and Jeff Gothelf, as their books provide excellent design-centric views of product discovery.
Books on Product Discovery:
“Escaping the Build Trap: How Effective Product Management Creates Real Value” by Melissa Perri. Preview the book here.
INSPIRED: How to Create Tech Products Customers Love by Marty Cagan
Continuous Discovery Habits: Discover Products That Create Customer Value and Business Value by Teresa Torres
Sense & Respond, How Successful Organizations Listen to Customers and Create New Products by Jeff Gothelf & Josh Seiden
Check out this talk from the author goes into more detail around the Delivery Trap and product discovery:
