Deciding what to build, how to build it, and what it must earn
Strategy used to mean months of workshops that produced a document. Now it means a working prototype in days, a decision about what to build and how to build it, and a clear statement of the business pain it must remove, with a way to know it's working. You'll see it before you fund it.
The pain point comes first
- Days to settle a claim.
- Cost per order shipped.
- The month-end scramble nobody measures.
Where this fits
A new problem starts the loop. What you learn running the software feeds the next turn.
How cheap prototypes change the economics of discovery
Discovery documents existed because building was expensive. Description stood in for the thing. That reason is gone.
The economics of discovery: description priced against a working prototype.
How the strategy stage runs, from the first call to the signed Blueprint
Every decision here is cheap to change. Everything after it is expensive. The stage runs as four steps on one clock, with the right people in the room, and each step ends in something you can hold.
Day one
01Name the pain
What are we trying to solve, and can we measure it?
Measurable pains get a baseline. Unmeasurable ones still count: anecdotal evidence is evidence. Whoever owns the pain is in the room from day one.
YouStrategistYou hold: the problem, stated — baseline and owner
The first days
02Walk the process
Which steps never made it into any system?
We walk the process end to end with the people who run it. The steps that live in spreadsheets and inboxes are usually where the money leaks.
YouStrategistYou hold: the process, drawn — spreadsheet steps included
The same week
03Prototype it
What could we put in front of users this week?
Your business users prototype it themselves, or we prototype rapidly and they correct what they see. Rounds, not requirements.
YouDamco agentStrategistYou hold: a corrected prototype — rounds, with reasons
Before funding
04Decide: build or buy
What shouldn't we build at all?
Build, buy, a database plus an agent, or nothing. Every call lands with a reason and a trade-off, written into the Blueprint.
StrategistYouYou hold: the Blueprint, first revision
Every step ends in something you can hold, and every rejection is written down with its reason.
How success is measured, agreed before anything is funded
A build that cannot say what it moved is a cost. Strategize therefore ends with a success contract: the pain's number, its measured baseline, the target the software must reach, and the person who owns it. The same number returns every week in the Operate KPI report, so the question “did this pay for itself?” has an answer on a schedule, not an anecdote.
Where the pain has no clean number, the contract still names its evidence and its owner — an unmeasured pain is not an unmanaged one.
The success contract
sample · agreed before funding
Days to settle a claim
What makes this hard at enterprise scale
The four steps are simple to describe and difficult to run in a large organisation. These are the four places they usually break, and what a well-run stage does about each.
- Owners disagree
- Two directors can own halves of the same process and want opposite things. Name one owner for the outcome before step one, and record what the others gave up. A trade-off nobody wrote down gets reopened in the middle of the build.
- Some constraints are not negotiable
- Your regulator, data residency, the core you cannot replace, the two-week close. These belong in the room at step one, not raised as risks at step four. They decide what is worth prototyping at all.
- Prototypes get rejected
- That is the point of building them. A round thrown out costs days and saves quarters. What matters is that the rejection is written down with its reason, so the same idea does not return next year as a new proposal.
- This is one loop among many
- A large organisation runs several of these at once, in different functions, on different clocks. One Blueprint across them is what stops the fourth programme contradicting the first, and what makes the fourth cheaper than the first.
These questions deserve owners. Strategize with us →
The four deliverables Strategize owes Build
Everything above lands as something Build picks up. Each row names who takes it:
| Deliverable | What it is | Who takes it up |
|---|---|---|
| The problem, stated | The pain, its baseline where there is one, and the person who owns the outcome. | Build prices and sequences against it |
| The process, walked | The end-to-end model, including the steps that only ever lived in spreadsheets and inboxes. | Build builds to it; it becomes the map kept next to the code |
| The prototype, corrected | The rounds your business users touched, with what they changed and why. | Build starts from working software, not a requirements document |
| The Blueprint, first revision | Build, buy, database plus agent, or don't fund. Each call with its reason and its trade-off. | Build follows it; deviation is a revision, never a quiet exception |
How Damco runs the strategize stage
- We run the sessions and make every deliverable. You bring a few calls with the right decision makers.
- Everything discussed is recorded and kept next to the work, so no context is lost between strategy and build.
- People with decades of deciding what to build guide the calls. You keep the decisions.
Need a thought partner for your strategy?