From Developer to Product Owner

It’s a change in mindset, approach, and the expectations toward you. Choose carefully.

IgorVetushko /Depositphotos

You are a Developer on a Scrum Team, and for one reason or another, the opportunity to become a Product Owner has presented itself to you. What does this change look like, and is it the right move for you?

When you make the shift from Developer to Product Owner, you are no longer solving problems. Instead, you are figuring out which problems to maximize the value of the product resulting from your Scrum Team’s work.

The impact of your work is no longer measured in how much you personally deliver, but in the value that your organization and your users derive from the product you own.

(While value is an abstract term, there are ways to measure it. Check out our list of the most insightful metrics for Product Owners.)

This is easier said than done, though. And there are three changes you need to make to your mindset and ways of working to make that transition successful should you decide to do it. You must understand and internalize that:

  • You are no longer building things; you are shaping them.
  • You don’t do estimation and planning any longer; you articulate and prioritize.
  • You are no longer expected to come up with ingenious solutions for getting things done. Your job is to set the boundaries for what will—and won’t—be done.

To see why this is, let us take a closer look at each of those changes.

From Building Things to Shaping Them

One of the biggest changes in mindset and approach when moving from Developer to Product Owner in a Scrum Team is that, as a Developer, you build things, while as a Product Owner, you shape them.

You shape the work by defining it in the form of items on the product backlog.

Whether they are themes, epics, features, and/or user stories, those items must be specific enough so that the Developers on your team understand what needs to be built but abstract enough to leave room for creativity and interpretation.

Here, it is important to understand that your focus is no longer on how things are done but on what needs to be done and why—and this “why” must be supported by a clear definition of business need and customer value.

This concept is best described in Chapter 2, “Principles of Shaping,” in Ryan Singer’s book Shape Up: Stop Running in Circles and Ship Work That Matters. Singer and his team at Basecamp have made the book available to read for free online, and you can buy a hard copy for $30 if you like.

“When we shape the work,” he writes, “we need to do it at the right level of abstraction: not too vague and not too concrete. Product managers often err on one of these two extremes.”

He explains that words are too often too abstract and wireframes too concrete. Then, he gives an example of how he shaped Basecamp’s Dot Grid Calendar (called Schedule) with a rough but clear and thoughtful definition.

Let go of building and practice shaping. It takes a while to learn the ropes, but your team and customers will thank you once you do.

From Estimating and Planning to Articulating and Prioritizing

As a Developer, you were expected to estimate and plan the work. As a Product Owner, you are now expected to articulate and prioritize it, leaving the estimation and planning to the Developers.

Your challenge is no longer to come up with solutions for implementing items on the product backlog. It is to come up with the backlog items themselves, articulated clearly and prioritized accordingly.

Articulation is the contents of your work items (themes, epics, features, and/or user stories), and priority is the order in which they make the most sense to get done.

When in doubt, adopt the three Cs of Extreme Programming (XP):

“User stories have three critical aspects,” writes Ron Jeffries, one of XP’s three founders, on his blog. “We call these Card, Conversation, and Confirmation.”

User stories, he says, are written on cards. “The card does not contain all the information that makes up the requirement. Instead, the card has just enough text to identify the requirement, and to remind everyone what the story is.”

Jeffries says the requirement itself should be communicated to the Developers through the act of conversation, “an exchange of thoughts, opinions, and feelings.” The conversation is largely verbal, but it can be supplemented with artifacts (the story, a sketch, a flowchart, etc.).

He explains that the best supplements are examples—and the best examples are those that can be acceptance tested. In the XP world, acceptance tests are black-box system tests. “Each acceptance test represents some expected result from the system,” it says on the framework’s website.

Remember this as you set about to create items on your product backlog. 

Your goal as a product owner is to define the “what” and the “why” and then have a conversation that leads to the Developers on your Scrum Team having a clear understanding of the work.

You come out of the Sprint Planning event not only with a Sprint Backlog but with an agreement between you and the Developers on the definition of—and the results from—the work that’s planned to be done.

In its simplest form, all you need is a rough but concrete sketch, a high-level but explicit enough story, and a bulleted, testable list of acceptance criteria that allows everyone involved to be able to know when exactly they are done.

From Finding Solutions to Drawing Boundaries

“I finally found a way to get this done!” Say it as a Developer on the standup, and everyone will be excited and curious. Say it as a Product Owner, and those same people will frown (and secretly curse you).

As a Developer, you were expected to push the boundaries of technology by finding ingenious solutions to get things done. As a Product Owner, you are expected to work with your Scrum Team to manage expectations for what can and cannot realistically be done.

Take an economic view of the world. Time, money, and opportunity are not limitless. They are limited, scarce resources, and you have been appointed as their allocator.

A team can only do that much at a time, and there is an opportunity cost: to do A, you have to forgo B. To do B, you have to forgo A. When you take one path, and it turns out to be a dead-end, it takes twice as long to go back and get as far as you did on the other.

The Product Owner’s world is not one of technical ingenuity, but of economic selectivity. How do you get everything you can out of all you’ve got?

Your Scrum Team can not do everything at once, and your product can not cover every use case for every customer. The best way to get nothing done is to make every single item in your Product Backlog and Sprint Backlog a priority.

Around the clock, 365 days a year, you are negotiating internally with your Scrum Team and externally with your stakeholders as you try to balance the needs of the customer with the development of the product while leaving room for the team to experiment and grow.

You do that by spending 20% of your time defining what to do and 80% of your time defining what not to do. The latter is harder because it requires you to think through your options and make trade-offs when you can choose between A and B, but you can never have both.

Is This the Right Move for You?

Your day in the life of will change from solving problems and building solutions to identifying problems and shaping solutions. From focusing on verification (is this done?), you will shift your attention to validation (is this the best thing to do all things considered?).

Last but not least, your career path will change from Director of Engineering and, ultimately, Chief Technology Officer to Director of Product and, ultimately, Chief Product Officer.

By Dim Nikolov

Jack of all trades and master of none. Dim is a Certified Scrum Product Owner (CSPO) and Certified Scrum Master (CSM). He has a decade of experience as a stakeholder, member, leader, and coach for agile teams.