Can you be a Product Owner without coding?

Can you be a Product Owner without coding?

You have just moved from operations into a Product Owner (PO) role for the shopping app of a fictional store. In your first refinement session, you bring a request from customer support: let customers add a note when they place an order. You expect it to take an afternoon. The developer looking at it says: “That's about 8 points.”

Without thinking, you say: “It's just one text box, why so much?” The room goes quiet for a few seconds. Nobody explains, and you leave feeling you said something wrong without knowing what.

This is an illustrative situation. The short answer to the question in the title is yes. You do not need to write code to be a PO. But you do need enough technical literacy to ask “what goes into those 8 points?” instead of “why so much?”. The two questions sound close, but one opens a conversation and the other shuts it down.

This article covers that literacy: the concepts worth knowing, why a “small” change may not be small, why estimates always carry uncertainty, and how to ask questions so developers feel you are solving the problem with them, not checking up on them.

Why is working with developers hard when you cannot code?

It is not because you are bad at the job. There are three easy traps, and naming them shows you where to fill the gap.

• You only see the surface. You see the screen; developers see the data, the systems wired together and the fragile parts of old code. The same change looks like two different sizes to the two of you.
• You speak different languages. You talk in users and business outcomes; developers talk in APIs, tables and environments. Neither is wrong, but without shared words a meeting becomes two people talking past each other.
• You are not sure where you stand. Some new POs avoid asking for fear of looking clueless. Others overreach and tell developers how to build it. Both damage the working relationship.

The Scrum Guide 2020 draws a fairly clear line. Developers are the people in the Scrum Team committed to creating a usable Increment each Sprint. The word is not limited to people who write code: testers and designers who build the product are Developers too. The Scrum Guide says how backlog items are turned into an Increment is up to the Developers, and that the Developers who will do the work are responsible for sizing it.

The PO is accountable for maximising the value of the product and for keeping the Product Backlog transparent, visible and understood. So your part is what, for whom, why, and in which order. The how belongs to the Developers. Technical literacy is not there to take over their part, but to make the two parts fit.

How technical does a Product Owner need to be?

A conceptual grasp is enough to start. You need to know what each thing is and how it affects cost, time and risk. You do not need to know how to build it. The table lists ten terms you are likely to hear in your first weeks, in plain words.

If you want to look at the data yourself instead of waiting for someone to pull it, the beginner SQL article is a sensible next step. Being able to read a table makes the question “what happens to existing data?” far more concrete.

• SQL for new Product Owners

Why is a “small” change not always small?

Back to the order note. On screen, it is one text field. Underneath, it can touch many places:

• The database needs somewhere to store the note, and someone must decide what old orders get.
• The order API has to accept new data, check its length and block odd characters.
• Older versions of the mobile app on customers' phones still send orders the old way, so the system must accept both.
• Warehouse staff need to see the note in the admin screen, and maybe on the printed slip that goes with the parcel.
• If the delivery partner generates that slip, adding the note depends on whether they accept a new field.

Then there is technical debt. Martin Fowler describes it with the image of a loan: weaknesses inside the system make each new feature take extra effort, and that extra effort is like interest. If the ordering code carries debt, even a small-looking change pays interest. Fowler also suggests paying debt down gradually in the parts of the code that change most often, since that is where the most interest is paid.

So when a number surprises you, do not read it as developers being slow. Read it as a sign that there is a hidden part you have not seen yet, and ask until you can see it.

Why are developer estimates uncertain?

Mountain Goat Software explains story points as a measure of effort, in which complexity, risk and uncertainty have to be combined into one number. A task the team has done many times and a task that must connect to a system nobody has touched can get the same number, with very different certainty.

Some things only surface once the work begins: an old function nobody remembers writing, a partner who answers slowly, an odd data case. That is why an estimate is a forecast for planning, not a promise. Pushing developers to lower the number does not make the work smaller. It only makes the plan less honest.

Your job is not to argue with the number but to understand what it contains, which parts are solid and which are not, and whether the uncertain part can be reduced before you commit to anyone else.

How to work with developers without coding: four steps

One practical approach is to take each important item through the four steps below. Much of this happens in refinement, where the team breaks down and clarifies backlog items before they enter a Sprint.

Step 1: bring the problem, not the solution. Instead of “add a note field”, say “customers need to tell the warehouse things like office-hours delivery, and right now they call the hotline to do it”. When developers know the problem, they can suggest a cheaper path you did not think of. You can still share the requester's proposed solution, as long as you present it as one option rather than a fixed requirement.

Step 2: ask to understand, not to decide for them. Good questions reveal the hidden part: what goes into the number, which part is least certain, what depends on outside parties, what happens to existing data. Avoid questions that already contain a method, such as “can't we just add a column?”.

Step 3: choose trade-offs together. Once you see the hidden part, ask whether a smaller version would still solve the core problem. Developers state the cost and risk of each option. You decide which option is worth more and set the order. When you take the options to stakeholders, state the cost of each one.

Step 4: agree, then let the team work. Record the decision in the backlog item. Then protect the team's focus time: batch your questions into one message or a set slot instead of pinging all day, and do not ask “is it done yet?” every few hours. When a new request lands mid-Sprint, do not forward it straight to a developer; handle it as described in the article on mid-Sprint change requests. This is the article's suggestion, not a Scrum rule.

• Effective backlog refinement
• Change requests mid-Sprint

What questions should a PO ask developers?

Wording matters a lot. The table sets lines that slip out easily beside lines that open a conversation.

These questions are also worth keeping ready for any technical discussion:

• Is there a smaller version that still solves the core of the problem?
• Does this depend on another system or team?
• What happens to existing data after this change?
• If something breaks after launch, how do we notice and roll back?
• Is there technical debt here worth dealing with at the same time, and what would it add?
• What do you need from me to clear up the uncertain part: data, a decision, or someone to ask?

Example: asking about an 8-point estimate

Back to the order note. This is an illustrative conversation, replayed using the four steps above.

Notice what the PO does not do. The PO does not argue with the 8, does not suggest how to store the data, and does not promise anyone a date before asking. The PO asks what the number contains, which part is uncertain, and proposes a smaller version tied to the original problem. The 3-point estimate is still the developer's number.

When replying to customer support, the PO presents two options with their costs. The full version with the printed slip: about 8 points, still depending on a delivery partner who has not answered. The admin-screen version first: about 3 points, but warehouse staff must open the screen to read notes instead of reading them on the slip. The requester can choose once the price of each option is clear.

Template: questions for a technical discussion

Copy the template into your meeting notes or the backlog item description. You do not need every question. Pick the ones that fit the item.

BEFORE THE DISCUSSION
[ ] The problem fits in one sentence: who faces what, and how they cope today.
[ ] The outcome: what changes once it is done.
[ ] Any solution the requester proposed is written as one option, not a fixed requirement.
[ ] Any real deadline, and why it exists.

DURING THE DISCUSSION
[ ] Which parts of the system does this change touch?
[ ] What goes into the estimate? Which part is least certain?
[ ] Does it depend on another system, team or outside party?
[ ] What happens to existing data?
[ ] Is there a smaller version that solves the core problem? Roughly what does it cost?
[ ] Is there technical debt here worth handling at the same time? What would it add?
[ ] If it breaks after launch, how do we notice and roll back?
[ ] What must be clarified before we agree? Who does it, and by when?

AFTER THE DISCUSSION
[ ] Record the chosen option and what is left out this time in the backlog item.
[ ] Note the cost of each option to report back to the requester.
[ ] Batch remaining questions into one message instead of sending them one by one.

“What must be clarified before we agree?” is an easy question to skip. If nobody asks it, the uncertainty is still there and surfaces mid-Sprint, exactly when it is hardest to handle.

Common mistakes new POs make with developers

• Saying “it's tiny”. You are judging the size of work you only see the surface of. Ask what the number contains instead of ruling on its size.
• Telling developers how to build it. Suggesting “add a column” or “reuse that screen” steps into the Developers' part. Describe the problem and the outcome, and let them choose the method.
• Treating estimates as commitments. Promising stakeholders a date from the first number, then pushing the team to hit it. Tell stakeholders what is a forecast and what is still uncertain.
• Nodding when you do not understand. Pretending to know a term means you still cannot ask the right question next time. Saying “I'm not clear on this, could you explain it at a conceptual level?” is normal.
• Hiding the business context. Passing on a request without the why takes away the developers' chance to suggest something better.
• Pinging all day. Every message breaks a stretch of focus. Batch your questions unless something is truly urgent.
• Treating technical debt as the developers' private problem. Debt slows down the very features you want to ship. Ask what it costs and weigh paying it down against other work in your priorities.

Summary

• You can be a PO without coding. You need enough conceptual technical literacy to ask good questions and understand the answers.
• The PO owns what, for whom, why and the order. Developers decide how and size the work.
• A “small” change can touch the database, the API, older app versions, third parties and technical debt. Ask until you see the hidden part.
• An estimate is a forecast that includes risk and unknowns. Reduce scope instead of squeezing the number.
• Four steps: bring the problem, ask to understand, choose trade-offs together with their costs, agree and then protect the team's focus time.

I am writing more PO situations in this same format, with templates you can use straight away. If you would like the next one by email, subscribe to the newsletter below.

• Get new articles by email

Frequently asked questions

Can you be a Product Owner without knowing how to code?

Yes. The Scrum Guide leaves how to turn backlog items into a usable Increment to the Developers, while the PO looks after value and ordering. What a PO needs is enough technical literacy to ask good questions and understand the answers.

Which technical concepts should a PO know?

A conceptual grasp is enough to start: frontend, backend, API, database, test environments, deployment, technical debt and estimates. You need to understand how they affect cost and risk, not how to build them.

Why can't developers give exact estimates?

Because an estimate combines the amount of work, complexity, risk and unknowns into one number. The unknowns only show up once the work starts, so an estimate is a forecast for planning, not a promise.

Sources to check

• Scrum Guide 2020: Developers, Sprint Planning, Product Backlog
• Martin Fowler: Technical Debt
• Mountain Goat Software: What Are Story Points?

Related articles

• PO vs PM vs BA: what is the difference?: How PO, PM and BA really differ, how the lines move between outsourcing firms, product companies and startups in Vietnam, and how to read a job description to see which role it actually is.
• Your first 30 days as a Product Owner: what to do each week: A four-week plan for a new PO: listen and map, understand users and metrics, own a small slice of the backlog, then make a first decision and agree expectations with your manager.
• From BA, QA or developer to Product Owner: what to learn?: Which BA, QA and developer strengths carry over to the PO role, which blind spots to watch, and how to build PO experience inside your current job.
• Product Owner interview questions: answer with real situations: The kinds of questions in a PO interview, how to answer with a concrete situation, what to do when you do not know, and what to ask the interviewer.