What we mean by value
This page explains what we count as value, the forms it takes, and how to recognize it at each checkpoint. Our engineers work from the same definition (their guide).
value
noun
Value is meaningful progress toward something that matters to the client.
Meaningful means the progress makes a useful difference to the client: it helps them do something useful, improve something that matters, or make a better-informed decision.
The test: What can the client now do, do better, or decide because of this work?
Start with one sentence
You don't need a specification, metrics, or a business case. Bring a problem, an idea, or an outcome you want:
- "I want customers to book appointments themselves."
- "Scheduling takes too much of our time."
- "I'm not sure whether we should build this."
That's enough to begin. We don't expect you to know everything up front, and we don't pretend to either. Working out what you need is something we do together: we agree on a useful next step, show you progress, and learn from how you react. The direction usually gets clearer through conversations, demonstrations, prototypes, and real use.
Changing your mind is part of the process. If seeing the work shows you need something different, that's progress. The work that got you there helped you decide, and we adjust course with you.
The forms value takes
Value doesn't have to be a new feature, or show up in your finances right away. It can come in small steps, prevent a problem, or build up over several iterations. It does need a clear connection to what you need.
Capability
Do something useful that wasn't possible before.
- Customers can book an appointment online.
- Dispatchers can assign a technician straight from the schedule.
- A deployment pipeline, so the booking app can be released and run.
Improvement
Make something easier, faster, safer, or more reliable.
- Staff confirm a booking in one step instead of three.
- A backup that has actually been restored in a test.
- Booking rules kept in one place, so the holiday-hours change is one edit.
Clarity
Better understand a need, answer a question, or choose a direction.
- The current scheduling tool already supports the workflow.
- After trying the booking flow, deposits move ahead of reminders.
- A technical experiment shows the proposed design can handle both locations.
Some work builds toward these results over several iterations. We explain what it enables, what has been verified, and what remains.
Clarity counts when it helps move the work forward. More information on its own isn't value.
"Don't build it" can be the most valuable answer. If an existing tool solves the problem, you've saved money.
What you'll see at each checkpoint
At the end of every iteration, we explain the progress in your language, answering three questions:
- What changed?What now works, improved, became clearer, or moved forward.
- Why does it matter?How it connects to what you're trying to do.
- What does it enable next?What you can now do or decide, and what remains.
- What changed?
- Customers can now choose an available appointment and receive confirmation.
- Why does it matter?
- This removes the scheduling back-and-forth for those bookings.
- What does it enable next?
- Next, we can add cancellation or put the workflow in front of customers.
- Not yet
- We have not yet measured actual staff time saved.
We also recommend what to do next, and which block size fits it (details).
Ready to use, or a step toward it
We always tell you which. Anything we show you carries a stability level, and we say what remains before you can rely on it in your business. A prototype isn't ready for real use just because it works in a demonstration.
How much progress was made
| How we show progress | What we don't use as proof of value |
|---|---|
| Capabilities completed | Hours spent |
| Improvements verified | Lines of code or tickets closed |
| Risks addressed | The capacity you bought |
| Decisions made possible | A single value score, or everything in dollars |
When a number helps and we can support it, such as manual steps removed or time per task, we use it and label it as measured, estimated, or expected.
Capacity, value, and business results
These are three different things:
- BoughtCapacityAn engineer's time, talent, attention, and focus for one iteration, at a fixed price.
- Delivered and shownValueThe useful progress that capacity contributes to, explained at every checkpoint.
- Realized later, not promisedBusiness resultsMore bookings, saved staff time, or lower costs, through adoption and use of what was delivered.
- A block doesn't come with a fixed amount of value. Not every iteration finishes a feature. When one ends with a finding or a step toward something larger, we say so plainly.
- We don't promise business results. They depend on how the software is adopted and used, and on more than the software. We won't imply guaranteed revenue or savings.
You can always question the work
You don't have to judge the technical details to judge whether the work helps you. Ask whether something is useful, and tell us when priorities change. Our engineers explain technical needs and tradeoffs in plain language, so you can weigh them and redirect the work.
Frequently asked questions
Do I need to know exactly what I want before we start?
No. One sentence about a problem, an idea, or an outcome is enough. Clarifying it is part of the work, and the direction usually gets clearer once you see something working.
What if I change my mind about something you've built?
That's normal, and often the most useful thing an iteration does. Seeing working software is how most people find out what they really need. We tell you what still carries over, and what changes, and then follow your new direction.
What if an iteration doesn't produce a new feature?
That can still be good progress, such as a finding that settles a decision, a risk removed, or a foundation the next feature needs. We tell you what it is, why it matters to you, and what remains. If it didn't move you forward, we say that too.
Why spend capacity on work I can't see, like backups or tests?
Because it protects or enables something you care about. We explain the specific risk it reduces or the work it makes possible, not a general appeal to "best practices." If the reason doesn't make sense for your situation, ask, and we'll talk through the tradeoff.
Will you tell me how much money the work will make or save?
We can tell you what changed and, where it's supportable, measure things like steps removed or time per task. The business result depends on how the software is adopted and used, so we won't promise revenue or savings, and we label estimates as estimates.
What if I don't think the work was useful?
Tell us, at the checkpoint or any time before. We'll explain what we did and why, and change direction if it isn't serving you. You also decide at every checkpoint whether to buy the next block (Sharing risk).