How we decide what to build

Good software is a by-product of good thinking.

That has always been true. What changed is the cost of getting it wrong. When execution was slow, a bad decision was expensive but visible: you had months to notice. Now that building is fast, a bad decision arrives fully built.

Don't over or under solve

The most common failure in product work is not building badly. It is solving the wrong amount. Over-solving burns budget on problems the business does not have yet. Under-solving ships something that cannot carry the weight it is about to be given. Both look like progress while they are happening.

Knowing which users to solve for, to what degree, and at what point in a company's life is the judgement call underneath every other one. It is also the one that is almost never made explicitly. We make it explicitly.

The eight product lenses

Before any architecture is designed, a product is examined through eight lenses. The point is not thoroughness for its own sake. It is that architecture decided before these are understood is architecture decided on assumptions.

1. Business model: what kind of business this actually is
2. Stage of business: where it is in its life, which changes what "good" means
3. Users: who they are, and which of them the product exists to serve
4. Data: what powers the product, and what it produces
5. Elements: the component parts and how they relate
6. Stack and infrastructure: what it runs on and why
7. Fitness functions: what the product must optimise for
8. UX and UI: how it is experienced

The rule attached to them: completely understand the product and its users before beginning architecture design.

Business model first

Great product thinking starts with knowing the business model, because the business model determines who the users are and how many kinds of them exist.

Most digital businesses fall into four groups: technology or licensed software, something-as-a-service, an extension of an offline business, and marketplaces. Each produces a different user landscape, and each has failure modes the others do not.

A detail that repeatedly matters in practice: almost nothing is purely B2B. It is usually a business selling to a business that serves someone else again, and the critical question is which of those people is the customer and which are the users. Marketplaces get complicated faster than anything else, because they carry two sets of customers at once. And there are always outliers, the validators and surveyors and lenders who exist in the product only because the primary business does. Mistaking one of those for a primary user distorts everything downstream.

Stage of business

The same product decision can be right and wrong depending on when it is made.

We map products across a maturity progression: idea, proof of concept, thin MVP for a single user type, thin MVP for multiple user types, scaling, and enterprise. The appropriate approach shifts across that progression, and so does the definition of quality. What an MVP owes its users is not what a production release owes them.

Naming the stage explicitly, at the start, is what stops a team building enterprise architecture for a proof of concept, or shipping proof-of-concept foundations into something about to carry real load.

Requirements as the north star

Before solutions, we define the metrics that will guide every decision. Cost efficiency when the budget is tight. Reliability when downtime costs the business money. Extensibility when the product will be stretched in directions nobody has named yet. Scalability, security, auditability, maintainability, usability.

These are not universal goods to be maximised. They are trade-offs, and choosing them deliberately is what makes later decisions arguable rather than personal. When a technical choice is challenged six months in, the answer is a requirement that was agreed at the start, not an opinion.

Design defines behaviour

Design, for us, is not decoration at the end, and it is not only the interface. Design settles behaviour: the states, the edge cases, the system responses, the unhappy paths. It is a way of reasoning about a problem by making it concrete, so a prototype becomes an argument you can hold and a flow becomes a hypothesis you can test.

Design and requirements work as an interplay rather than a sequence. Sometimes exploration comes first and shapes what the requirements need to cover. Sometimes a drafted requirement surfaces the need for design. Either way, the thinking is settled before execution begins, because if an engineer or an agent has to guess, the thinking was not finished.

Making it tangible

A product is a series of user journeys, so you have to know three things: who the user is, where they are going, and how they get there. And for that, a picture beats a thousand words.

When the thinking changes the answer

Two examples, both anonymised to industry only. Neither carries figures, timeframes or detail specific enough to identify the client.

A logistics business, on where the product should live. They came to us to build fleet management as a mobile application, which is what everyone in that sector builds. Discovery found that the people actually doing the managing were doing it at desks, not in the field. So we built it for desktop instead. It cost them less than the thing they asked for, and it was used by the people who had to use it.

A client in discovery, on how much to build. The plan was to build the whole product. Working through it, one part of the communication stack stood out as the point most likely to fail, and everything else depended on it working. So the first thing being built is a proof of concept on that one component. If it holds, the rest follows on solid ground. If it does not, they have found out now rather than after building everything around it.

Neither of these is a heroic story, and that is the point. This is what the lenses and the maturity stage produce when they are applied honestly: usually a smaller build, a cheaper build, or a different build than the one that walked in the door. It also costs us revenue more often than it wins us any, which is the part worth saying out loud.

Drawing it before building it

Making the thinking concrete is what stops it staying an opinion.

We draw journeys early and roughly. Not perfect, not polished, iterated collaboratively. Then the data and the relationships underneath them. Then the unhappy paths, which is where most of the real thinking hides. Then the user stories marked clearly against the flow.

The discipline is to resist depth too early. One user story with immaculate acceptance criteria and nothing else drawn is a trap. Work one layer at a time, and be willing to go back up a level when something further down proves the layer above wrong.

MO_PRO: how this stays repeatable

None of the above is worth much if it lives in a few senior heads.

MO_PRO is MOHARA's internal product thinking programme. Thirteen sessions, run Socratically rather than lectured, with homework between them and a case study presentation at the end where people apply it to their own live projects. It has been taught across the company, with sessions led by our own engineering, design, QA and validation leads rather than bought in.

That is the difference between a methodology and a slide about a methodology. Everyone building at MOHARA has been through the same reasoning, which is why the judgement holds when the person in the room changes.

Curiosity, bravery, empathy

Underneath the method is a disposition. Curious about how the work could be done better. Brave enough to push at the boundary rather than sit still. Empathetic to the people we build for and with.

Which is also why friction is treated as feedback here. When something resists, that is data about what to improve, not an obstacle to push through.