handbooksThe six mindsets
Outcome-oriented, customer-centric, collaborative, visual, experimental, continuous. What each one means in practice and the habit that tells you whether you actually hold it.
- Six mindsets sit underneath every technique in this handbook. Skip them and the techniques become theatre: a tree nobody updates, interviews nobody acts on.
- They are not personality traits. Each one shows up as an observable habit, or it does not show up at all.
- The two that teams find hardest are outcome-oriented and continuous, because both require giving something up rather than adding a practice.
Why start here
You can run a workshop, draw a tree, and interview a customer without any of this working. The techniques are easy to copy and easy to hollow out. What makes them produce anything is the set of beliefs underneath, which is why Torres puts the mindsets before the habits.
Read each one and ask the diagnostic question in the last column honestly. A mindset you cannot answer yes to is one you hold in theory.
The six
| Mindset | What it means | You hold it if |
|---|---|---|
| Outcome-oriented | Define success as the value your code creates, not the code itself. Begin with the end in mind. | Your team can name the number it is trying to move without opening a document |
| Customer-centric | The purpose of a business is to create and serve a customer. Their needs sit alongside business needs, not underneath. | You can quote a customer from this month, in their words |
| Collaborative | Decisions are made by the team, drawing on what each person knows. Every member has a say. | Your engineer has changed a product decision, recently |
| Visual | Get thinking out of your head and onto a wall. Draw flows, trees, maps. | There is an artifact someone outside the team could point at and question |
| Experimental | Name your assumptions and go get evidence. Prototype to test, not to impress. | You have killed one of your own ideas in the last quarter |
| Continuous | Discovery runs through development rather than sitting at the front of it. | You talked to a customer last week, and the week before |
The two hard ones
Outcome-oriented
The obstacle is not understanding the difference. Everyone understands the difference. The obstacle is that a feature roadmap is comfortable, it makes promises other people can plan around, and an outcome does not.
A fixed roadmap communicates false certainty. It says we will ship these six things on these dates, and it says nothing about whether any of them will work. Trading that for "we will improve activation by 8 points, and we do not yet know how" is a real loss of comfort for everyone around you. That is why it is hard, and no framework removes the discomfort.
Continuous
Weekly is the part people quietly drop first. It gets dropped because any single week's interview feels skippable, and it does. The value is not in one conversation, it is in never being more than seven days away from the customer when priorities shift.
Interviewing sporadically means every round starts from scratch. You spend the conversation rebuilding context you have lost. Interviewing weekly means each conversation adds to a picture you already hold, and the picture is warm when a decision lands on your desk.
Visual is not decoration
Drawing is thinking. When you sketch the customer experience, you find the gaps in what you know, because a gap in a drawing is a blank space and a gap in a sentence hides behind vague words.
This is also what makes group work honest. If three people describe a customer journey out loud, they will nod along and believe they agreed. If those same three people draw it separately first, the differences are impossible to talk past. Experience maps puts this to work.
Collaborative does not mean consensus
Every member having a say is not the same as every decision needing agreement. The trio exists because a designer sees usability, an engineer sees what is cheap to try, and a product manager sees the business case, and a decision made without one of those views is worse.
Collaborative slides into design by committee when the goal becomes agreement instead of a better decision. The fix is to make the disagreement visible and specific, then decide, rather than discussing until the disagreement wears out.
Experimental, in the plainest terms
Every idea you have rests on things that must be true for it to work. Most of those things are invisible until you name them, and the expensive ones are invisible until you launch.
The habit is to write down what must be true, sort by how much it matters and how sure you are, and go find evidence on the ones that matter most and are least certain. That is the whole method. Hidden assumptions turns it into a routine.
Pick any feature currently in your backlog. Write down three things that must be true for it to work, and mark which of the three you have actual evidence for. If the answer is none, you have found what to do this week.