Understanding, here, means connecting your work to what happens before and after. Who meets the problem? How does that person find the solution? What does it take to deliver the service, maintain it, and know whether it helps?
In a company, those questions touch customers, product, distribution, revenue, costs and operations. In a community group or a personal project, they can be about participants, access, the time available, handovers and continuity. Money counts when it conditions the action; it is not the only measure of what the action is worth.
A community group opens sign-ups for a workshop. The form works, but the person on the welcome desk does not get the information they need. Participants have to repeat on the day what they already wrote. Understanding the handover between sign-up and welcome helps you choose a useful improvement without rebuilding the whole system.
Nobody needs to know everything to the same depth. Start with a dependency that changes your decision. Finance can explain a cost, support a use, operations a continuity constraint. Someone starting out can ask for a guided tour; an experienced person can examine an assumption that has become habitual.
This work takes time and access. Prepare a precise question with the people who know the context. Some documents or contacts are not directly reachable: a prepared example or a guided conversation may then be enough. Understanding other people’s craft does not grant you a mandate to decide in their place.
The cards gather four subjects: needs and feedback from the field, what you are able to build, what the service promises, and the routes to use. Commercial and software situations stay present, with their limits. You can translate them to a smaller project without needing a company or a public audience.
If you are growing a team, organise the exchanges and make their costs visible. If you are supporting a project, you can offer an introduction that was accepted, time to observe, or help checking an assumption. Support does not require taking control of the work.
A sign of progress: you can explain one consequence of your choice for another person or another activity, separating what you observed from what you assume.
You can then come back to framing, prepare an attempt, or read the delivery cards to put a solution to the test of reality. These capabilities grow together.
The cards in this capability
- 4.01 Talk to the person who has the problem
- 4.02 A feature request is not the problem
- 4.03 Support is product research with angry participants
- 4.04 The customer does not care about your architecture
- 4.05 What you can build decides what you can sell
- 4.06 Choosing a vendor is signing up for three years
- 4.07 Understanding cannot be delegated
- 4.08 Distribution is part of the product
- 4.09 Marketing is not decoration
- 4.10 Talk about the problem before you talk about yourself
- 4.11 An audience takes longer to build than a product
- 4.12 ⇄ An estimate asked for after the decision is not an estimate
- 4.13 ⇄ Customer access is a budget, not a value
- 4.14 ⇄ You cannot ask for distribution while funding only features