handbooksStart small
What to do when your company does not run discovery, will not give you a designer, and has already decided what you are building this quarter.
- Do not wait for permission or a reorganization. Start with the part of your work you already control.
- Weekly customer interviews are the keystone habit. Establish that one and the others follow from it.
- Handed a solution instead of a problem? Work backward to the customer need it assumes, and put that on a tree.
- One interview and one informal trio beats a perfect process you are still waiting to be allowed to run.
The situation this page is for
Your company does not do discovery. There is a roadmap for the quarter that was written without customer input. You do not have a dedicated designer. Engineers are measured on velocity and would not be given time for interviews. Nobody is asking you to change any of this.
This is the normal case, not the exception. Teresa Torres spent years in companies with limited support from leadership, and the way through was not to win an argument about process. It was to keep a strong sense of agency over her own work and start with what she could already do.
Start with what you control
You almost certainly control more than it feels like.
| You cannot | You can |
|---|---|
| Change the quarterly roadmap | Understand which customer need each item assumes |
| Get a full-time designer | Ask a designer to join one interview a month |
| Stop feature requests | Ask what the requester expects it to do for customers |
| Run a formal research program | Talk to one customer this week |
| Change how success is measured | Write down what you expected before a release, and compare after |
None of these need approval. All of them produce something you can point at later, which is how the argument eventually gets won: not by advocating for discovery, but by having found something nobody knew.
The keystone habit
If you can only build one habit, build weekly customer interviews.
It is the keystone because everything else follows from it. Once you are talking to customers weekly, you accumulate opportunities, and opportunities create the need for a tree. You start wanting to test ideas quickly, which creates the pull toward prototypes. Decisions start referencing what a customer said last Tuesday, which is what changes how the team argues.
Start with one interview a week. Recruit from support conversations, sales calls, or a small prompt in the product. Keep a snapshot for each one.
If you genuinely cannot reach customers yet, interview people who resemble them. It is weaker evidence than the real thing and far better than nothing, and it builds the habit while you sort out access.
Build an informal trio
You do not need an org chart change to work as a trio. You need a designer and an engineer who will spend a little time with you on decisions.
Ask for something small and specific. Not "join our discovery process," which sounds like a standing commitment to an unfamiliar thing. Try one 30-minute customer conversation, or fifteen minutes to look at three ideas before you pick one. Almost nobody refuses that, and people who attend one interview usually ask about the next.
The guiding question stays the same: how can I include all three disciplines in as many decisions as I can?
Working backward from a handed-down solution
You will often be told what to build. Instead of arguing about whether it is the right thing, work backward to the need it assumes.
Ask: if our customers had this, what would it do for them?
That question gets you a customer need, which you can put on a tree as an opportunity. Now you have somewhere to hang what you hear in interviews, and a way to notice if the assumed need turns out not to be the real one. You are also not blocking anything, which matters for being allowed to keep doing this.
Sometimes the assumed need holds up and the feature is fine. Sometimes you find the real need next to it, and you can propose an alternative with evidence rather than an opinion.
Use the release you already have
After a release, run a short review with whoever asked for it. Two questions:
- What did we expect this to do?
- What did it do?
This is not a retrospective on the process, and it works best when it does not sound like one. It is a straightforward comparison that quietly introduces outcome thinking to people who were only thinking about output. Do it a few times and the question "what do we expect this to change?" starts getting asked before a release rather than after.
Anti-patterns
- "That will never work here." Sometimes accurate about the full process, almost never accurate about the next small step. Ask what you can do this week instead of what the company should adopt.
- Waiting to be shown how. There is no starting signal coming. Do one interview badly, then do a better one.
- Copying the whole method at once. Trying to run interviews, trees, ideation, and assumption testing in your first month, in an organization that supports none of them, ends with all four abandoned.
The honest version
Progress here is slow and mostly invisible for a while. What changes it is a moment where you know something about a customer that nobody else in the room knows, and it turns out to matter. That moment buys you the next bit of room, and the one after that buys more.
Start small. Iterate from there.