Product Planning Is Shaping the Work

Planning sounds responsible until I ask the uncomfortable question.

What am I actually planning?

That is where a lot of product development gets fuzzy. Teams say they are planning a feature, a roadmap, a sprint, a release, or an application. But those words can hide the real work. Planning is not writing a list of things to build. It is not arranging tickets in a backlog until the board looks orderly. It is not estimating a vague idea until it feels safe enough to start.

Product planning is the act of making the work clear enough to bet on.

That is why Shape Up has stayed useful to me as a way of thinking. Basecamp's language is intentionally different from standard agile planning. They talk about shaping the work before betting on it. They talk about pitches instead of endless backlogs. They talk about appetite instead of estimates. They talk about six-week cycles and circuit breakers. Underneath the terminology is a practical idea: do not send a team into delivery with a cloudy problem and call it empowerment.

The team needs space to solve.

But they also need a shaped problem.

A shaped project is not a full specification. It does not answer every implementation detail. It does not remove judgment from the people building. It gives the work boundaries. It says what matters, what does not, what the user needs to accomplish, which business rules are real, which risks are known, and how much time the company is willing to spend.

That is the planning I trust.

The blank page problem#

The hardest part of building software is often not typing the first line of code.

It is knowing what that first line belongs to.

A blank program can be intimidating because there are too many possible starting points. Which variable comes first? Which function? Which data model? Which screen? Which service? Which test? Which interaction? Which piece of state?

The answer should come from the shape of the product.

Before code, I want to know how the application flows for the user. I want to know where the user starts, what they are trying to do, what state changes after each action, which branches are possible, and where the experience ends. I want to know the business logic, meaning the odd rules that only make sense inside this user's world.

That phrase matters: business logic.

It is not just validation code. It is the reality of the user's work. The approval rule that exists because finance closes the month on a particular schedule. The exception path that matters only for one customer segment. The eligibility rule that feels arbitrary until you understand the contract. The order in which a manager reviews work because the operation would break if approvals happened earlier.

These details are often where the product lives.

If planning skips them, implementation becomes guesswork.

Shape before build#

Shape Up's first move is to shape the work before it is considered for a build cycle.

I like that because shaping respects uncertainty without surrendering to it. A raw idea is too loose for a team to execute. A full spec is usually too rigid and expensive. Shaping sits between those extremes.

The shaper asks:

• What problem is worth solving?
• What does the solution roughly look like?
• What are the boundaries?
• What is intentionally out of scope?
• What is the appetite?
• What risks could make this fail?
• What does the team need to know before deciding whether to bet?

The shaped work should be concrete enough that leaders can make a decision and builders can begin. It should still leave room for design and engineering judgment during execution.

That balance is hard.

Too little shaping and the team spends the cycle discovering that the project was not ready. Too much shaping and the team becomes a factory for someone else's decisions. The useful middle is a clear direction with open implementation space.

In product terms, shaping turns "we need a better workflow" into something closer to "users need to move a request from intake to review to approval without losing context, and the first version should handle the happy path plus the two known exception states. We are not solving advanced permissions in this cycle."

That is planning.

It creates edges.

The betting table#

Shape Up also uses the idea of a betting table.

That framing is useful because it makes planning feel closer to investment than scheduling. A team has limited capacity. Every project chosen means another project waits. The question is not only "is this a good idea." The question is whether this is the best bet for the next cycle.

I like the word bet because it admits uncertainty.

Planning is not prophecy. A roadmap is not proof. A pitch is an argument. The betting table decides which shaped projects deserve real team capacity now.

For that meeting to work, the pitch has to carry enough information:

• The problem.
• The appetite.
• The proposed shape.
• The user flow.
• The main risks.
• The tradeoffs.
• The no-go areas.
• The expected outcome.

If a project cannot be explained at that level, it is probably not ready to be built. That does not mean it is a bad idea. It may need more shaping, more discovery, a smaller appetite, or a different framing.

This is also where technical debt belongs.

Debt should not be an invisible tax that engineers complain about after planning. If debt inhibits better product development, it should be shaped as part of the work or shaped as its own bet. The argument should be concrete: this debt slows cycle time, hides defects, blocks a workflow, makes data untrustworthy, or prevents a safer architecture.

Otherwise debt becomes background noise.

User flow is product logic#

When I plan an application, I want to draw the flow.

Not because mockups are pretty. Because flow reveals logic.

Even a simple sketch can show the relationship between scenes, screens, states, and actions. Start here. Click this. Move there. If this fails, go to this state. If the user wins, show this. If the user exits, save that. Arrows between screens are not decoration. They are a map of the product's behavior.

Game development makes this obvious.

For a Breakout clone, I might sketch a Start scene, a Game scene, and an End scene. The arrows show how the player moves from the start screen into the game, then from the game into a win or lose state, then back to restart. That visual flow tells me what program state I need.

The same pattern applies to business software.

A request system might have Intake, Review, Approval, Revision, Rejected, and Complete states. A reporting workflow might have Draft, Validated, Published, Deprecated. A customer support workflow might have New, Triaged, Escalated, Waiting, Resolved. A data governance workflow might have Proposed, Classified, Approved, Monitored, Retired.

Once those states are visible, the implementation questions become less abstract.

What causes the state to change? Who can trigger it? What data is required? What validation happens? What notification is sent? What audit record is written? What happens if the user goes backward? What happens if an external system fails?

That is why flow sketches are serious planning artifacts.

They turn "the app should be easy to use" into inspectable behavior.

Mockups help create the feature list#

Mockups are not only for designers.

A rough mockup helps the team see what the product is asking the user to understand. It shows which information appears together, which action is primary, which states are missing, and which decisions the interface is forcing.

After the mockup, the feature list becomes less imaginary.

For a Breakout clone, the sketch might reveal features like:

• Start screen.
• Game screen.
• End screen.
• Paddle movement.
• Ball movement.
• Brick collision.
• Score tracking.
• Lives or ball deaths.
• Restart button.

For a business application, the same exercise might reveal:

• Intake form.
• Request status.
• Approval queue.
• Comment thread.
• File attachment.
• Notification rule.
• Exception state.
• Audit history.
• Role-based action.

The feature list should not be a dump of ideas. It should fall out of the flow.

That is the difference between planning from imagination and planning from interaction.

High-level architecture is the bridge to code#

After the flow and feature list, I want a high-level architecture.

This does not need to be a 40-page document. It needs to help the builder know where to start.

For a small game, the architecture might be:

Objects
- Brick with isHit behavior
- Paddle with move behavior
- Ball with move behavior
 
Scenes
- Start
- Game
- End
 
Logic
- Ball and brick collision
- Paddle and ball angle changes
- Win and lose state transitions
 
User interaction
- Keyboard movement
- Mouse or button scene changes
 
User data
- Ball deaths
- Brick hits
- Score

For a workflow application, the same categories change shape:

Domain objects
- Request
- Reviewer
- Approval
- Comment
- Attachment
 
States
- Draft
- Submitted
- In review
- Needs revision
- Approved
- Rejected
 
Business logic
- Eligibility checks
- Approval routing
- Required fields by state
- Notification timing
- Audit logging
 
User interaction
- Intake form
- Review queue
- Approval actions
- Revision comments
 
User data
- Request history
- Attachments
- User role
- Decision record

That architecture gives the first coding moves some shape. Maybe the team starts with domain objects and state transitions. Maybe they spike the review queue. Maybe they build the happy path with fake persistence. The exact choice depends on risk.

The important thing is that the team is no longer staring at a blank program.

They have a map.

Technology choices should follow the shape#

"What technology will you use?" is a real planning question.

But it should not come before the shape of the work.

Technology choices should follow product constraints. If the product is a low-latency interactive tool, the architecture has one set of needs. If it is a governed enterprise workflow, it has another. If it is a data product, the reliability and lineage requirements matter. If it is a game, frame rate, asset loading, input handling, and state transitions matter.

A shaped project should make technology tradeoffs more concrete:

• Does this need real-time collaboration?
• Does it need offline support?
• Does it need auditability?
• Does it need strict role-based access?
• Does it need complex state machines?
• Does it need streaming data?
• Does it need integrations with existing systems?
• Does it need to scale now or later?

Without those answers, technology selection becomes taste.

Taste matters, but it is not enough. Good architecture is sympathy for the problem.

Discovery before commitment#

Shaping should not happen in a conference room sealed away from users.

The notes ask the right questions. Are we visiting customers to observe how they work? Are we learning what issues they face? Are we understanding what could make them better at their job? Are we conducting usability evaluations? Are we tracking and analyzing behavior? Are we fixing known problems and simplifying workflows?

Those questions belong in product planning.

A team can build exactly what stakeholders requested and still miss the user's actual work. Users often describe the tool they imagine, not the constraint that hurts them. Stakeholders often describe the report they want, not the decision they need to make. Engineers often see the system boundary, not the human workaround that makes the current process survive.

Discovery closes that gap.

It can include customer visits, interviews, usability tests, prototype walkthroughs, behavior analytics, support ticket review, sales call review, and workflow observation. The method matters less than the intent: understand the user's real context before committing delivery capacity.

I am especially interested in workflow observation because people often cannot fully explain their own work from memory. They skip steps in the retelling. They forget exceptions because exceptions feel normal. They do not mention the spreadsheet that holds the process together because they are embarrassed by it or because everyone uses it.

Watching the work changes the plan.

Fast experiments protect capacity#

Planning should also create room for fast, safe, capital-efficient experiments.

Not every idea deserves a full build cycle. Sometimes the right move is a prototype, a fake door, a manual concierge test, a design walkthrough, a data pull, or a thin technical spike. Experimentation here is not theater — it is the cheapest way to reduce the riskiest uncertainty before the team spends serious capacity.

The shape of the experiment should match the risk.

If the risk is usability, test the flow. If the risk is technical feasibility, spike the integration. If the risk is demand, test the offer. If the risk is data quality, profile the dataset. If the risk is operational adoption, simulate the workflow with real users.

A good experiment produces a decision. Build, reshape, shrink, defer, or stop. If an experiment only produces interesting notes, it may still be useful, but it is not yet a planning input.

Technical debt is product risk#

Technical debt can inhibit better product development as directly as a bad roadmap.

It slows changes. It makes estimates unreliable. It hides defects. It scares engineers away from important areas of the codebase. It makes testing brittle. It forces teams into manual workarounds. It blocks new product directions because the old architecture cannot support them cleanly.

So I do not like treating debt as separate from product planning.

Some debt is just engineering housekeeping. Some of it is strategic. The strategic kind should be shaped and discussed with the same seriousness as feature work.

The pitch should explain:

• What product capability is blocked?
• What risk is increasing?
• What workflow is slower because of the debt?
• What defects keep repeating?
• What cheaper future work becomes possible if this is paid down?
• What is the appetite?
• What is out of scope?

That framing moves the conversation from "engineering wants time to clean things up" to "this debt is constraining the product system."

That is a better conversation.

Timeline is appetite, not fantasy#

The question "what is your timeline" can produce bad behavior if the work is not shaped.

Teams estimate vague ideas. Leaders treat estimates as commitments. Scope expands because the idea was never bounded. The team works nights to defend a date that was attached to the wrong version of the project.

Shape Up's appetite language is useful here.

Instead of asking how long the imagined perfect version will take, ask how much time the business is willing to spend on the shaped version. Is this worth two weeks? Six weeks? A longer strategic bet? If the appetite is small, the shape must be smaller. If the appetite is large, the risk and opportunity should justify it.

This reverses a common planning mistake.

The team does not estimate an undefined solution and then try to survive the estimate. The organization defines appetite, shapes a solution that fits, and cuts scope aggressively when the work tries to grow.

That creates healthier constraints.

Planning artifacts I trust#

I trust planning artifacts that help a team make decisions.

For a shaped product bet, I would want:

• Problem statement.
• User flow sketch.
• Business rules.
• Appetite.
• No-go scope.
• Feature list.
• High-level architecture.
• Risks and open questions.
• Discovery evidence.
• Technical debt constraints.
• Success measure.
• First delivery slice.

That may sound like a lot, but most of it can be lightweight. Shared clarity matters more than documentation weight.

A one-page pitch with a flow sketch and a rough architecture can be more useful than a polished requirements document that avoids the hard questions.

The artifact should expose the shape of the work.

Failure modes#

The first failure mode is planning from features instead of flow. The team collects a list of desired features but never maps how the user moves through the system.

The second is shaping without discovery. The pitch sounds good internally, but nobody watched the user struggle.

The third is technology-first planning. The team chooses tools before the product constraints are clear.

The fourth is unbounded appetite. The team says yes to an idea without deciding how much time it deserves.

The fifth is hidden business logic. The weird rules are discovered during implementation, which means the project was never really shaped.

The sixth is debt denial. The roadmap assumes the system is healthier than it is.

The seventh is mockup theater. Screens exist, but state, transitions, permissions, and failure paths are missing.

The eighth is over-shaping. The shapers answer every detail, leaving builders no room to solve.

The ninth is betting on vague language. Everyone agrees to the same words and later discovers they meant different things.

These are not process problems in the abstract. They become product defects.

How I would start#

If I were planning a new application, I would start with a blank page, but I would not start with code.

First, I would describe the user and the job. Who is this for? What are they trying to accomplish? What do they do today? What makes the current workflow painful?

Then I would sketch the flow. Start state, main path, end state, exception paths. I would draw arrows because arrows force the logic to show itself.

Then I would write the business rules. The strange ones first.

Then I would create a feature list from the flow, not from imagination.

Then I would break the architecture into domain objects, states, logic, user interaction, and user data.

Then I would name the risks. Usability, feasibility, data quality, performance, compliance, adoption, technical debt.

Then I would decide the appetite. How much is this worth right now?

Then I would decide whether to bet, experiment, reshape, or stop.

That is a planning process I can work with.

The point of shaping#

The point of product planning is not to remove uncertainty.

It is to make uncertainty visible enough to manage.

Shaping gives a team something real to discuss before the work consumes a cycle. Mockups reveal flow. Flow reveals business logic. Business logic reveals architecture. Architecture reveals implementation choices. Discovery reveals whether the shaped idea has contact with reality. Debt review reveals whether the system can support the bet.

That is the chain I care about.

When planning is weak, teams build from blur. When planning is too heavy, teams build from someone else's frozen assumptions. The better middle is shaped work: clear enough to bet on, open enough to build well.

That is how product development becomes less about filling a roadmap and more about designing a path from user reality to working software.

Sources#

• Shape Up: Stop Running in Circles and Ship Work that Matters
• Shape Up: Shaping the Work
• Shape Up: Betting
• Product discovery guide
• Nielsen Norman Group: Field Studies
• Martin Fowler: Technical Debt