Our approach
How we develop an opportunity.
We start with a problem and the people who live with it. We build the product and the system around it, then test whether people rely on it, how it should reach buyers and whether it is worth further investment. The stages give the work an order. A finding at one stage often changes a decision made at another.
Stages 01–02
Explore
Identify a problem that could support a company, and understand the people who live with it.
- 01
Select the opportunity
Is this problem worth building a company around?
We start with a workflow that is expensive today and ask what has changed in the work or the technology to make a better answer possible. AI-native product strategy asks whether that calls for a new product, a redesigned workflow or both, and whether the outcome would justify a company. Exploration is broad, and much of it is meant to rule things out: problems that are too small, already well served or not improved by AI.
- 02
Understand the buyer and the user
Who uses it, who pays for it and what would make each of them change?
Customer discovery starts here. The person who uses a product is often not the person who buys it, and the two measure value differently. We learn how the work is done today, what a better result would be worth and what the time to value would be. Organizational readiness matters as much as the software: integration, review time, trust and a change in habit.
Stages 03–05
Build
Define the first product, design the system around the model and test it against the work.
- 03
Define the initial product
What is the smallest product someone would rely on?
This is where product strategy becomes a product definition. The first product does one valuable part of the job well enough to be depended on. We decide what it will do, what it leaves to people and what it should never do on its own, and product management keeps that scope honest as evidence arrives. The definition sets the first technical question: how much autonomy the work actually needs.
- 04
Design the system
Where does the path stay fixed, where does an agent decide and what may it touch?
Steps with a known path belong in a fixed workflow, which is usually easier to predict and test. It is not always cheaper: running every step on every case can cost more than an agent that stops once it has enough. An agent loop is worth its cost when the next step depends on what the last one found. The architecture makes that choice. Orchestration coordinates the execution, the tools and the handoffs in a human-agent workflow. Several agents are worth the overhead when work can run in parallel, needs more context than one window holds or benefits from specialized tools and instructions.
The harness keeps task state, chooses what each call sees and carries out tool calls. A ticket, an email or a retrieved page is useful evidence only when the data is ready, which means the records can be reached and they are current. Prompt injection is the failure in which such material is treated as an instruction. Where tools are reached through MCP, OAuth scopes can narrow what a connection may access. Decision rights still have to say which actions an agent may take on someone’s behalf and which exceptions a person must handle.
Related terms: Agentic workflows · Orchestration · Multi-agent · Agent harness · Context engineering · MCP · Decision rights
- 05
Build and evaluate
Does it do the work, and can we tell when it does not?
Product development starts with working software aimed at the assumptions that matter most. Evaluations run representative tasks and check the state each run leaves behind. We rerun them when the model, prompt or tools change, and those results guide the next design change. Traces show what a run saw, which tools it called, what they returned and where time and cost went.
Retries are bounded. Where repeating an action could cause harm, recovery relies on idempotent operations or explicit duplicate checks. Uncertain or high-risk cases return to a person for exception handling, and the record keeps what was allowed, what was attempted and what actually changed as separate facts.
Related terms: Evaluations · Eval-driven development · Observability · Recovery · Idempotency
Stages 06–08
Commercialize
Test whether people adopt the product in their daily work, choose how it reaches buyers and decide how much more to invest.
- 06
Test adoption
Do people rely on it in the work they already do?
Enterprise AI adoption is tested in daily work, beyond a successful pilot. Adoption at scale requires organizational readiness, human-agent collaboration and a reasonable time to value. Repeat use, accepted outputs and less rework are useful signals; measured gains in cost, quality or throughput provide stronger evidence of organizational effectiveness. When those gains persist, workflows and operating models may change, sometimes as part of broader AI transformation. Willingness to pay and sustained use are early signs of product-market fit, though not proof. Traces help show where the product falls short.
- 07
Choose the route to market
How does it reach the buyer, and at what price?
Go-to-market strategy shapes the product as much as the sales plan. Direct sales, a partner or a platform each ask something different of the product, the price and the team. Pricing starts from measurable business value, what an accepted result is worth and what it costs to deliver, discarded attempts included, rather than from the volume of model usage.
- 08
Decide on further investment
Has the case grown stronger?
Commercialization proceeds as a series of commitments. Portfolio prioritization requires a regular operating cadence for reviewing customer evidence, technical progress, adoption and commercial value. Those reviews inform investment allocation, from how much time, people and capital come next to whether a partnership or a dedicated team is needed. A stronger case justifies more. A weaker one changes the work or ends it, and ending it is a legitimate result.
Working back
What one stage learns, another uses.
Three illustrative cases, drawn as the arcs on the stage map above. In each, something learned at one stage changes a decision made at another.
05 Build and evaluateinforms04 System design
Evaluations show the agent is unreliable on one kind of case.
That case moves to a fixed path that ends with a person, and the agent handles the rest.
06 Adoptioninforms03 Initial product
Reviewers in a pilot check every output line by line.
The first product shows the evidence behind each output. Without it, review time erases the gain.
02 Buyer and userinforms07 Route to market
The buyer measures the service in resolved cases.
Pricing can follow resolved cases, provided the system records which ones it can stand behind.
We commit further where the case strengthens and change direction where it does not.
If you are working on a problem this approach suits, we would like to hear about it.