Thinking about doing
Some thoughts on workflows
The agile workflow, according to most books, is: To Do → Doing → Done. But in reality, it’s rarely that clear-cut.
Depending on the team, doing might mean researching, prototyping, designing, coding, testing, or waiting for stakeholder feedback. Even done can vary—does it mean code is merged? Deployed? Validated?
As a product manager, it’s your job to define and align on what these stages mean, and when exactly something is being worked on. You have to define both the workflow and the roadmap. (And if you don’t, your manager—also a product manager—will.)
If you’ve studied Software Engineering, you’ve likely come across the classic comparison:
Waterfall is linear—you finish one step before starting the next.
Agile (or Spiral) is iterative—you build a bit, evaluate, and continue.
Think of house painting.
In Waterfall: you build the house, then paint everything.
In Spiral: you build one room, start painting it, then build the next. The client can react to the colour while you build.
Planning is where “doing” becomes important
The subtleties of doing come into play during planning. You might be doing something while:
researching,
interviewing users,
designing mockups or wireframes,
drafting PRDs, epics, or stories,
while developers are working on it,
while it’s being tested,
or once it's been merged into the main codebase.
Two views: Product and Engineering
I like to divide the backlog into two views—one for product and one for engineering.
Ideas or features live in the product backlog.
Stories and tasks live in the engineering backlog.
Here’s how I break down the product backlog:
Repository: Just an idea written down—maybe sourced from data, observation, user feedback, or stakeholder input.
Discovery: Where the PM begins researching the idea—competitive analysis, rough wireframes, and early collaboration with engineers and designers.
Design: For frontend features, the designer leads this phase—user research, testing, and refining the experience. For backend features, this is where we define APIs and data flow. (Though engineers don’t always call it “design”—often that happens in the next stage.)
Grooming: The engineer leads here—scoping complexity, and working with the PM to define epics, user stories, and tasks.
Ready for Delivery: The story is ready to be picked up in sprint planning or pulled in a Kanban flow.
Delivery: The idea moves through the engineering workflow.
Adjustment: Engineering needs more input, or stakeholders are testing something.
Done: The feature is live. Sometimes technical debt remains, or the experience sparks new ideas that go back to the repository.
The engineering backlog has its own statuses:
To Do → Ready for Development → Development → Testing → QA → Deploy → Done
Which I will not define because this my diary as a PM, not EM.
Avoiding the Waterfall trap
People often fall back into Waterfall habits—moving a large idea step by step until it’s in the hands of users. This is where the PM has to work their magic: slicing the idea small enough to deliver value without tying up resources for too long, but not so small that it becomes meaningless.
Being agile doesn’t mean moving in circles. It means delivering value quickly and often.
Why so many stages?
Is it all just bureaucracy?
When I worked with a small team at a bootstrapped startup, a sticky note on the wall and the word doing were enough. But as teams grow, stories become more complex. Stakeholders demand transparency. We need to know if doing by design is already done, and so on.
People go on holiday, get sick, or leave the company. Knowing the exact status of a story ensures the work continues.
When you're experimenting and willing to cut corners (i.e. accept some debt), a PM, designer, and engineer can move fast. But as complexity grows—shared design systems, event tracking, data integrity—you often need more than one person and one ticket.
Final thought
One of my professors once told me:
Picasso didn’t start by painting Cubism. He began with traditional painting, and only later broke the mould. If he’d started with Cubism, no one would have taken him seriously.
The point is: all these steps are guidelines. A PM’s job isn’t to blindly follow a workflow. It’s to deliver value. But workflows define the rules—on top of which there is room for innovation, improvement, or even breaking the rules.
The workflow should help you deliver value, not stop you from doing so.
If a workflow is preventing an organisation from delivering value, then the workflow must change.
If a workflow works for the team but not for one person, perhaps that person is in the wrong culture.
This post was improved with ChatGPT. It helped with grammar and some style checks. It also created the image accompanying it.
Waiting for someone to tell me that they wrote an idea in lovable or bolt or v0 or… and they got a complete feature.