Start With the User, Not the Backlog

Part II: Product Sense. Product sense is not a mystical instinct. It is the habit of connecting user pain, business goals, assumptions, constraints, and evidence before you build.

The Dashboard Nobody Needed

A client asks for a dashboard. The request is clear enough: show key metrics, add filters, allow export, make it responsive, and include role-based access.

The team starts estimating. The frontend work is moderate. The backend aggregation is heavier. Permissions need care. Export will take time. The feature becomes a multi-week project.

One engineer asks, "What decision will the user make from this dashboard?"

The room pauses.

After a few conversations, the team discovers the real problem. Managers do not need another analytics screen. They are missing exceptions. They need to know when an order is stuck, which customer is affected, who owns the next action, and whether the issue is getting worse.

The solution changes. Instead of a large dashboard, the team builds exception alerts, a small workflow queue, and a weekly summary. The work is smaller. The outcome is better.

The original request was a feature. The real need was faster exception handling.

Backlogs Are Not Sources of Truth

A backlog is a collection of assumptions, decisions, requests, compromises, and reminders. It is useful, but it is not sacred.

Backlog items often hide important context:

• A customer asked for something, but the pain behind it is unclear.
• A founder added an idea after a sales call.
• A product manager wrote a solution because the problem was hard to express.
• A support issue became a feature request.
• A competitor's feature created pressure.
• A technical limitation was disguised as product scope.

If you treat the backlog as truth, you build the surface version of the work. Builders respect the backlog but interrogate it. They know a ticket is often the start of a conversation, not the end.

User Request Versus User Pain

Users are experts in their pain, but not always in the best solution. When a user says, "I need a dashboard," the pain may be "I do not know what needs my attention." When they say, "I need export," the pain may be "I do not trust the data in this system yet." When they say, "I need more filters," the pain may be "The default workflow does not match how I think."

The builder's job is not to dismiss requests. It is to translate them.

Ask:

• What triggered this request?
• What is the user doing today?
• What workaround exists?
• What happens if nothing changes?
• How often does this pain occur?
• Who feels it most?
• What would a successful moment look like?

These questions turn a feature into a problem statement.

The 5P Builder Lens

Before building anything meaningful, pass it through the 5P Builder Lens. This lens is simple enough to use in a standup and strong enough to prevent weeks of waste.

For example:

Feature request: "Build a dashboard for support managers."

5P version:

• Pain: Support managers discover escalations too late.
• Person: Support managers handling enterprise accounts.
• Payoff: Faster escalation response and lower churn risk.
• Path: Start with a daily exception queue for accounts with unresolved high-priority tickets.
• Proof: Time to first escalation action drops by 30 percent.

The feature changed because the thinking changed.

How Engineers Can Join Discovery

Some engineers avoid discovery because they think it belongs only to product managers and designers. That is a mistake.

Engineers bring a unique lens. They know system constraints, data quality, integration complexity, edge cases, and hidden costs. They can identify smaller paths because they understand what is already possible. They can warn when a request will create long-term complexity.

You do not need to own the discovery process to contribute to it.

Join customer calls when possible. Read support tickets. Watch session recordings. Ask product managers for context. Talk to customer success. Study sales objections. Review analytics. Look at production logs. Notice where users struggle.

Product sense grows through contact with reality.

Writing a One-Page Product Brief

A builder should be able to create a short product brief before major implementation.

Use this structure:

• Problem: What painful user moment are we improving?
• User: Who experiences it?
• Current behavior: What do they do today?
• Business reason: Why does this matter now?
• Proposed path: What is the smallest useful solution?
• Risks: What assumptions could be wrong?
• Scope exclusions: What are we not building?
• Success signal: How will we know?
• Release plan: How will we ship safely?

This brief does not replace product strategy. It creates alignment before code.

Founder Lens

Entrepreneurs lose money when teams build requested features without validating the actual problem. Every unnecessary feature increases maintenance cost, product complexity, onboarding friction, and future decision load.

A builder saves money by preventing the wrong work. More importantly, they protect product clarity.

Developer Lens

Your daily work changes when you start from users.

You stop asking only, "What fields are required?" and start asking, "What moment are we improving?" You stop treating edge cases as annoying exceptions and start seeing them as user reality. You stop thinking of scope reduction as cutting corners and start seeing it as preserving the learning goal.

AI-Era Lens

AI can summarize customer feedback, cluster support tickets, draft user stories, and turn rough notes into briefs. But AI cannot know whether the source context is complete. It will often make a vague request sound precise.

Use AI to help structure discovery, not replace it. Give it real notes, support examples, business goals, and constraints. Ask it to identify assumptions and missing questions. Then verify with humans.

Common Mistakes

• Treating the backlog as truth.
• Asking only implementation questions.
• Accepting the user's proposed solution as the problem.
• Skipping small tests because the feature feels obvious.
• Writing user stories without user evidence.
• Letting AI turn vague ideas into confident documents.

Builder Checklist

• I can identify the user behind the ticket.
• I can describe the painful moment in plain language.
• I know the current workaround.
• I can explain the payoff.
• I can propose a smaller test.
• I can define proof before implementation.
• I can name what is out of scope.
• I can document the brief in one page.

Exercise: Rewrite Five Backlog Items

Choose five current backlog items. Rewrite each using:

• User
• Pain
• Current workaround
• Desired outcome
• Smallest test
• Success signal

If you cannot complete the fields, that is not failure. It is useful discovery.

Closing Thought

A backlog tells you what someone requested. The user tells you what hurts.

Key takeaways

• A backlog is a collection of assumptions and compromises, not a source of truth: a ticket is often the start of a conversation rather than the end of one.
• A user's requested solution and their actual pain are not the same thing; the builder's job is to translate the request into the real problem before building it.
• The 5P Builder Lens (Pain, Person, Payoff, Path, Proof) is small enough to run in a standup and strong enough to reshape a multi-week feature into a much smaller one.
• Engineers can join product discovery without owning it: reading support tickets, session recordings, and production logs builds product sense through contact with reality.
• AI can structure a rough request into a confident-sounding brief, but it cannot tell you whether the underlying context was actually complete, so it augments discovery rather than replacing it.