Product Thinking
Treating what you build as something with users whose problems it must solve — applied to internal platforms as much as to customer-facing products.
Definition
Product thinking asks whose problem is this, is it their most important problem, and how will we know if we solved it — before asking what to build. Its opposite is project thinking, which asks what to build and when it will be done.
Why architects need it
Two reasons, and the second is the one usually missed.
1. Architecture serves outcomes, not requirements. A requirement is a proposed solution someone has already chosen. Understanding the outcome behind it frequently reveals a simpler design — or reveals that the requirement solves a problem nobody has.
2. Internal platforms are products. A platform team building tooling has users, and those users have alternatives — including building their own. A platform that is mandated rather than chosen is one that would not survive adoption on its merits, and mandating it hides the signal that it is not good enough.
The consequences of taking that seriously: platform teams do discovery, measure adoption, treat developer experience as a feature, and maintain a roadmap. Platform teams that do not are service desks with a backlog.
What it changes in practice
- Outcome over output. "Reduce time to first deploy from three days to one hour", not "build a pipeline".
- Iteration over completeness. Ship the smallest thing that tests the hypothesis. Most architecture is designed against assumptions that could have been checked in a week.
- Adoption as the measure. A platform capability nobody uses has failed, regardless of its quality.
- Explicit users. "Who is this for" answered with a specific team, not "the organisation".
Where it can be over-applied
Some infrastructure is genuinely not optional and does not need product discovery: identity, audit logging, encryption in transit. Treating a compliance control as a product to be adopted voluntarily is a category error.
The distinction: enabling capabilities are products; mandatory controls are constraints, and the best form of a mandatory control is one embedded in an enabling capability so that compliance is a side effect of using the easy path.
Failure scenarios
- A platform built on assumptions, launched, and unadopted.
- Adoption mandated, so the quality signal is destroyed and the team never learns.
- Success measured in output — features shipped — rather than in outcome.
- No user research for an internal tool, because "we are the users", which is usually not true.
Interview question
"How would you know whether an internal platform is succeeding?"