Software has abstraction layers. Your spec should have them too.
I had to look up my own job title.
Before someone handed it to me, I had not heard the term product manager. It wasn’t a major. It hadn’t come up anywhere in my education. What I knew was that I wanted to work where business and technology meet, and entrepreneurship looked like the place to do that. Then, early in my career, I got christened the product manager of something.
So I looked it up. The definition made enough sense at a surface level that I took the title and got on with it.
The trouble started when the rubber met the road. There was no shortage of material on prioritization frameworks, discovery, roadmaps, and stakeholder management. What I could not find was an explanation of the thing I actually needed, which was how to define the product in the first place. Not what to build next. What the product is, stated in a way that survives contact with a business, a market, and an engineering team that all want different things from it.
That gap is not academic. It is where the job actually gets hard, and most of what gets called product management is downstream of it. Product-market fit is a result. Translating customer asks into a prioritized roadmap is an activity. Neither one tells you what the product is supposed to be.
The product that had been rewritten three times
Then I inherited one.
It was an incident response product, early in its sales cycle, with paying customers already on it. It was also a mess. The feature set had accumulated rather than been designed, and the pieces did not add up to anything you could state in a sentence. The product had been rewritten three times before I got there. Each rewrite left technical debt behind it, and each one left users a slightly different mental model to be confused by.
None of that was irrational. The company needed revenue, and the deals were real.
But it left me with a question I could not answer by prioritizing harder. How do I get this from what it is now to something where the customers are satisfied, the business is satisfied, and we occupy a sensible position in the market?
There was no clean way to balance those three. What I needed, at minimum, was a way to justify why the requirements I was writing and the order I was putting them in made any sense at all. Not a defensible-sounding story for a steering committee. An actual derivation, where each decision pointed at the decision above it.
That is what I did not have, and could not find.
Where the answer came from
It did not come from product management. It came from the way software gets described by the people who build it.
Systems architects work in layers: conceptual, logical, physical. In computer systems more broadly, layers of abstraction are the whole mechanism by which electrons moving through hardware end up as an application a person can use. Nobody at the application layer thinks about voltage. They don’t have to, because each layer is defined in terms of the one above it and implemented by the one below it.
That is a solved problem in engineering and an unsolved one in product. So I borrowed it.
Product abstraction is the same idea applied to product definition. The layers are the connective tissue between what the business is trying to do, what the product is trying to be, and what actually gets specified for development. In the ideal case, a requirement can be traced up to a goal and down to the code that implements it.
A car has a manufacturing specification, and every component in it traces to a spec. Software should be no different. The reason it usually is: a car is physical, and you can see when a part is missing. Software is abstract. A product can be missing an entire layer of its own definition and still look, from the outside, like it is going fine.
The chain
Seven layers, three sources, one boundary.
- Vision: the aspirational target you never actually reach
- Mission: the destination about a year out, and it is achievable
- Goals: the outcomes, each carrying a unit of measurement
- Use cases: how the product gets used to produce those outcomes
- Features: the capabilities the use cases require
- Requirements: the specifications a feature has to satisfy
- Acceptance criteria: binary checks, and the last layer product owns
Read it downward and it is a derivation. Read it upward and it is a justification. That second direction is the one that matters when someone asks why you are building what you are building.
The three sources, and why they are the actual problem
Here is the part I did not understand for years.
The top of the chain does not come from inside the product team. Three different constituencies supply it, and they supply different layers.
The market sets what the vision aims at. A vision is aspirational and permanently out of reach, which is exactly why software products are never done. But it is not arbitrary. It is calibrated against where the category is going, and the category is not yours to decide.
The company sets what can be committed to. The mission is the nearest destination that would make a real difference, on the heading the vision establishes. Goals are the measurable outcomes underneath it. Both are constrained by what the business can actually fund and what it needs to show.
The customers set what counts as working. Use cases are the scenarios where value actually gets realized, and the people realizing it are the authority on whether it did.
Below use cases, nothing is negotiated with anyone outside. Features are derived from use cases. Requirements are derived from features. Acceptance criteria are derived from requirements. That boundary is the most useful line in the diagram, because nearly every product dysfunction I have seen is a category error about which side of it something sits on.
A customer dictating a feature is a derived layer being treated as negotiable. A roadmap being mistaken for a vision is a negotiated layer being treated as derived. A quarterly revenue number standing in for a mission is the company being allowed to supply a layer it does not own.
Back to the incident response product. My three problems were not three problems. They were the three sources, pulling on three different layers, with nothing written down that connected them. The business wanted sales. The early customers had bought for specific features and expected them to keep working. And the market position, the thing nobody was accountable for, was drifting.
The first thing I did was get everyone to agree on the problem and the vision. Not because alignment is nice. Because until that layer exists, every argument below it is unresolvable, and prioritization is just whoever is loudest.
Then a goal with a unit attached to it: get the time it takes to respond to an incident down from hours or days to minutes.
Once those two existed, the rest became derivable. Supporting sales was still the business goal, and I still served it. But I could now say which deals moved us along the vision and which ones were pulling us off it, and I could say it with a derivation instead of an opinion.
Acceptance criteria are the handoff, not a step
Acceptance criteria are the last layer product owns and the first thing engineering is held to. That makes them a membrane rather than a seventh item on a list.
Everything above them is intent. Everything below them is implementation. They are the only layer that is binary, and that is what makes the handoff checkable instead of conversational.
Which brings up the honest limit of all of this. The best specification in the world does not produce the best product in the world. A product manager is only ever as good as the team building the thing, and software product management is not the requirements. It is what happens to them.
The objection I’d raise against my own argument
“This is waterfall wearing new words.” It is the first thing anyone with ten years in will say, and it deserves a real answer.
Waterfall fixed the content of each stage and treated change as failure. Abstraction fixes the relationships and expects the content to change constantly. A vision that never changes is a vision working correctly. A requirement that never changes is a requirement nobody checked. What the chain gives you is not stability, it is knowing what else moves when one thing does. Change a goal and you can see which use cases just lost their justification. That is the opposite of waterfall, which could not tell you that at all.
“Nobody has time to maintain seven layers.” You already maintain all seven. They are scattered across a board deck, a roadmap, a Jira epic, a sales one-pager, and somebody’s memory, and they contradict each other. The cost is not writing them down. The cost is that they are currently unwritten, so nobody can see where they disagree, and the disagreement surfaces as a prioritization argument that has no correct answer.
“You are describing a documentation problem as a theory.” Fair, and partly true. The layers are only worth the effort if they are connected to each other and to the code. A set of documents that name the layers but don’t trace between them is worse than nothing, because it looks like rigor.
What it actually bought me
The product we built off that chain sustained the company for years, until it was acquired.
I want to be careful about what I am claiming there. I did not control the company dynamics. Sales still drove more than I would have liked. Deals still bent the roadmap. What changed was narrower and more useful than a happy ending: I could define a product that made sense, defend why it made sense, and hand engineering something complete enough to build against. With the right engineering team, that was enough.
That is the honest scope of the thing. Product abstraction does not fix your company. It does not settle whether sales or product wins the argument. What it does is make the argument legible, so that the answer stops depending on who is in the room.
Prioritization stops feeling like guessing at exactly the moment there is something above it to derive from.
What’s the layer your team has never actually written down?
Part 2 goes to the top of the chain: where a vision actually comes from, and how to write a mission that is a destination rather than a slogan.