I Don't Want to Own the Backlog. I Want to Own the Problem.
Product got obsessed with artifacts. Roadmaps, tickets, story points — an impressive number of systems for organizing the work. The backlog isn't the product. The problem is.
Somewhere along the way, Product became very obsessed with artifacts.
Roadmaps.
Tickets.
Acceptance criteria.
Backlogs.
Sprint planning.
Story points.
We have created an impressive number of systems for organizing the work.
Sometimes I wonder if we remember that the point was to solve something.
I don’t want my biggest accomplishment to be:
“The backlog is extremely organized.”
Congratulations to us and our beautifully categorized problems.
I’d rather actually fix one.
Give Me the Problem Before You Give Me the Feature
One of the quickest ways to get me interested in something is to tell me:
“Everyone hates doing this.”
Now we’re talking.
Don’t start by telling me what button you want.
Tell me why you think you need the button.
Because maybe you need a button.
Maybe you need automation.
Maybe the data already exists somewhere else.
Maybe two systems should be talking to each other.
Maybe the entire process exists because somebody made a decision in 2019 and everyone has been politely suffering ever since.
The requested feature and the actual problem are not always the same thing.
Product should know the difference.
“We Need a Dashboard”
Do we?
I’m not anti-dashboard.
I’m anti-building-a-dashboard-because-someone-said-dashboard.
What are you trying to see?
What decision will you make with it?
Who needs the information?
How often?
What happens after they see it?
Because if the answer is:
“Well, we just want visibility…”
I’m going to have approximately 37 more questions.
Not because I’m difficult.
Okay, maybe a little.
But mostly because every feature creates something else we now have to maintain forever.
Software Is Not Free Just Because We Built It Ourselves
This is another thing Product needs to understand.
Every feature has a tail.
Someone has to maintain it.
Support it.
Explain it.
Update it.
Secure it.
And remember why the hell we built it three years from now.
So I’m constantly asking:
“What’s the smallest thing we can build that actually solves this?”
Not the smallest thing because we’re lazy.
The smallest thing because complexity is expensive.
If a 20% solution removes 80% of the pain, maybe we should start there.
Then watch what happens.
Less Predicting. More Proving.
This is where being able to prototype changes the way I approach Product.
Instead of sitting around debating whether something might work, I can often just try it.
Can I connect these systems?
Can I automate this step?
Can I pull this data?
Can I make a rough interface?
Can I prove the workflow in an afternoon?
Sometimes the answer is no.
Great.
We learned something cheaply.
Sometimes the answer is:
“Oh. This actually works.”
Even better.
Now we have evidence.
That’s what I want Product to do more of.
Less predicting. More proving.
AI Makes Experimentation Cheap
This is probably one of the things I’m most excited about with AI.
It has made the cost of trying dramatically lower.
And that’s different from saying the cost of production software is dramatically lower.
Those aren’t the same thing.
I can vibecode a prototype in an afternoon.
That doesn’t mean I’m tossing it into production at 4:57 PM and wishing everyone a nice weekend.
I can use AI to explore the idea.
Understand the shape of the problem.
Find the holes.
Show people something tangible.
Then decide what deserves to become real software.
That’s an incredible Product tool.
Then Give It to Engineering
If the prototype works, that’s when things get interesting.
Because now I’m not handing engineering:
“We think we want something that kinda does this.”
I’m handing them something real.
Maybe it’s ugly.
Maybe there are parts of the code that would make an engineer visibly uncomfortable.
That’s okay.
It’s a prototype.
But we’ve already figured out the workflow.
We’ve already tested assumptions.
We’ve already found out what users actually want.
We’ve already eliminated the things we thought mattered but didn’t.
I’m not trying to hand engineers a finished product and tell them their job is done.
Quite the opposite.
I want to hand them the 95% MVP so they don’t have to figure out where the hell to begin.
Then they can take everything we’ve learned and do what they do best:
Make it scalable.
Make it secure.
Make it maintainable.
Make it performant.
Make it something we can actually trust in production.
That’s a much better starting point than a ticket that says:
“Build dashboard.”
Product Should Create Clarity
Ultimately, I think that’s what my job is.
Not tickets.
Not ceremonies.
Not being the human shield standing between stakeholders and engineers.
Clarity.
What problem are we actually solving?
Why does it matter?
What’s the simplest way to test our assumption?
What should we build?
What shouldn’t we build?
What can I prototype before we commit engineering resources?
And what do we need to learn before we spend real time and money?
The backlog is just where some of those answers eventually end up.
It’s not the product.
The problem is the product.
And that’s the thing I want to own.