The Mindset Shift I Embraced To Go From Developer To Product Owner

Many years ago, when I started as a developer, I was what the industry considers a “code monkey” — someone whose work is to simply code whatever tasks are assigned to them without asking any questions.

This was great, because I was finishing college, and some days I could finish all my tasks in about 3 hours.

But I had the feeling that I was stuck. I wasn’t learning how to be better.

I had little to no further responsibility other than just coding.

And I couldn’t shake the feeling that I was building something mediocre — Or at least that I had no power to take it to it’s full potential.

On top of that, I had no idea about how to organize myself to:

• Know what features should be developed and which were a waste of time
• Prioritize my list of things to do.
• Deliver projects on time — I was especially bad at this one.
• Communicate efficiently with my team, which was super important while working remotely.

I needed to greatly improve my skills to grow from a regular developer into something bigger. Something that wasn’t just a code monkey.

I needed to become a Product Owner.

But wait, isn’t that supposed to be someone else’s job?

What is a product owner?

Not necessarily. Responsibility over anything can naturally increase and become more complex as our own mindsets and perceptions grow — transcending from the personal to the metaphysical scope.

First you take care of your body, then of your mind, then of your surroundings, and finally of the things that determine the state of your surroundings.

Product ownership, more than just a job role, is a position of responsibility. And since responsibility transcends the physical and the immaterial, it’s a responsibility that YOU can also take.

The scope of product ownership naturally grows in a holistic manner: From getting tangible results, to conveying team dynamics and finally creating a working system that goes beyond a single sprint.

The goal of all products is to give value to people. The goal of digital products is to give value efficiently and in an accessible manner, leveraging technology.

Product Ownership is taking responsibility for a digital product in a way that ensures that our final users (and the company building the product) get value from it.

For the product builders, the value they get is revenue.

For the final users, the value they get is satisfying their needs — the problems that the product is meant to solve.

The mentality shift

If I wanted to recreate who I was many years ago, I’d follow this formula:

• Just check in and out every day, receiving tasks and just implementing them
• Believe that my job ends when I write the last line of code
• Lack the skills to be promoted or exit to a better job
• Not care about what the users really need

You don’t want to be like old me — a code monkey. The opposite to that is being a Product Owner.

The mentality shift is that you don’t have to be a CEO or manager to care about the product and act like an owner.

If you think that you’re not being paid enough to do that, consider if maybe that’s the exact reason why you’re not being paid enough. You don’t have enough skills yet to be more valuable.

If you see that there are no opportunities for that in your current job, then you have to acknowledge that you’re in a place where growth is not possible. Consider changing your environment, which is the fastest way to change your behavior.

But even without opportunities to apply yourself as a product owner, making the mentality shift today will help you realize that what you’re actually supposed to do is not just coding.

We’re here to satisfy users’ needs.

The Path of The Owner

To be responsible for the product, first you need to be responsible for yourself.

This is why sharpening your own skills is the most important part.

Here are the seven skills that you need to start applying to Act Like An Owner in 2024.

Don’t worry, if applied correctly they will 10x your skills right by the end of Q1 (in around 3 months).

I’m intentionally leaving out the coding part, because that’s probably what you’re already most familiarized with.

1. Identify what your users really want

I work at Haystack News, a place to watch personalized local news.

Last year we received several complaints from different users saying that the Roku app was not showing them news from the channels that they cared about.

The problem was that users hadn’t made the connection that liking a video’s channel permanently added it to their front page recommendations.

You will discover that most of the time people don’t engage with your features because they don’t even know those features exist. Or don’t understand why they should care about them.

This made us wonder: What other pain points do our users have?

We found that the fastest way to know this is by just asking them.

It’s not the cheapest, but it’s worth mentioning because sometimes the companies building digital products don’t event consider it.

Don’t assume. Ask first.

2. Prioritize considering satisfaction and revenue

Make sure to balance satisfying the necessities of the company and of the users.

• If you focus only on revenue, people won’t be satisfied — and your revenue will plummet.
• If you focus only on user satisfaction, you won’t have enough budget to continue building the product.

We’ll talk more about user satisfaction in the next point

For most of digital apps, the metric that drives revenue is retention, which is the average amount of time that a user stays engaging in with your application.

Some people think that maximizing retention is unethical. I think that’s true only if the value you’re providing satisfies a superfluous need.

The solution to this is to make sure that you’re building something meaningful. This also compounds your motivation towards building it.

One pro tip: You might think that new shiny features are the best way to gain retention. But in reality, the most important thing to consider is quality.

3. Build the best experience to satisfy user needs

Same as we found the problem with users not liking channels, we also received complaints about users not being able to search for specific ones.

Turns out that it was possible. It just took too many steps to do it, and the users would get frustrated in the midst of it.

If it takes 15 steps to search for something specific in your app, people are just going to leave — even if you explain the steps to them.

If you work on a content app, you probably have a recommendation algorithm driving the front page of your application.

Sometimes we focus too much on this building this recommended experience, and neglect the happy paths to find specific content.

You want to minimize the effort that a user has to take to find what they want.

Make it too hard and people will just find them with your competitor.

4. Delivering projects in time

About 99% of developers base their project delivery estimations in simple guesses.

We usually take a list of requirements that we have for a sprint, and we guess the amount of time that each of them might take.

Then, we take the sum of hours, convert to work days and boom! We have a delivery date.

But this date is usually a wild guess, especially for a new project where you’re innovating — or if you’re just inexperienced with the problem at hand.

Think about it: You’re trying to guess how long things will take at the beginning of the project, which is the exact moment where you know the least about it.

As developers, we know that these guesstimates are not accurate. But most of the time, managers take them as facts — and hold us accountable when we end up not delivering in time.

This creates a toxic work environment where people are constantly paranoid that they won’t deliver whatever fantastical promise they made at the start.

Instead, you should consider reallocating your efforts into following what I call the SPEED+ System:

The effort of implementing this system is significantly less than trying to predict the future (very hard).

When planning projects, you don’t want to be a fortune teller. You want to be a meteorologist.

Studies have found that, as long as our tasks are small enough, just counting and multiplying them by our average velocity lets us forecast the delivery date.

A forecast is still not 100% accurate, but it’s no longer a guess because it’s based on historic data — your initial velocity — that gets adjusted ideally every day.

We can automate forecasting the expected delivery date, and only if it goes beyond the acceptable date we will schedule a call to either move this date forward or reduce the scope of the project.

So the best part is that by doing this we can reduce the amount of conversations we need to have with managers :) Instead of scheduling time for daily or weekly updates that could be invested in implementing the solution.

5. Communicate efficiently

This year I had the pleasure to mentor one of the most hardworking and code-quality driven developers I’ve ever met.

Sadly, these qualities were shadowed by his inability to communicate properly with the rest of the team. Enough for us to part ways at the end of the year.

Poor communication put them in a position where they were perceived as always stuck, not sure of what to work on and constantly delaying deadlines without proper reason.

After reflecting on this — and contrasting with the rest of my teammates’ success in communicating with each other — I’ve compiled nine tips to improve your communication with your team:

1. Give context to others as if they had forgotten about it completely

2. During meetings, make sure that you have anything you’ll need to show ready to share.

3. People lose attention fast. After giving context, start talking about your blockers immediately.

4. When communicating long ideas over Slack, write a long message with multiple lines instead of sending many small messages in a short period of time.

5. Try to come up with a solution before sharing a problem. Timebox it, to avoid loosing yourself in a rabbit hole. Share the things you tried as you explain the problem.

Always ask for help on public channels, so that if anyone else has a direct solution you can get it.

6. Always explain your problems from the concrete examples up to the general situation.

Bad:

Our backend has a machine learning setup that considers users preferences to show specific channels. The app uses the endpoint X, which has defines how the backend will generate user preferences. The other available endpoints for the same task are Y and Z. The endpoint X has a problem, so our users are not getting their frontpage recommendations.

Good:

Our users are not getting their frontpage recommendations. We’re using endpoint X when we should be using Y or Z. This is a problem because the backend sends us different recommendations depending on the endpoint used, and endpoint X has a problem. Specifically, endpoint X runs a different ML model than X and Z.

Explaining the concrete problem first will grab people’s attention, instead of boring them with topics that they already know about.

Plus, during voice calls you can stop for a second after each sentence to check if the rest of your team already has enough context up to that point.

That way you can stop the explanation there and start brainstorming a solution faster.

7. When you’re asked for progress status, communicate all the steps you’re taking towards a solution.

For example, for the question “How’s the project going?”

Bad:

Uhhh, still in progress.

Good:

I’m at 70%. Still need a couple of more days to finish.

This is enough if you know the person who’s asking already has enough context

Better:

I’m solving problem A. Next thing in my list is solving problem B. I’m coordinating with Alice and Bob to get it done. I’ve already scheduled / finshed meetings with them. I’ll have a demo / build ready by Friday.

8. Make it stupidly easy for other people to see what you want them to see.

Bad:

The document is in Notion

Good:

Here’s the Notion link for it

Better: Share the link in Slack, share it on Meet too if you’re on a call (but always Slack first). Send people screenshots of the specific parts you want them to check.

9. When sharing documents, make them digestible and personalized.

• If you want people to see your ideas one by one, make a slideshow presentation.
• If you need to share a version of your app to the team
  • For other devs, share a branch of the repository (name and link)
  • For QA, share a build and remind them to give you logs.
  • For management or other teams, share a build and publish a beta version. Ask for logs to the people who know how to get them.

6. Delivering the product

Deployment is not just about pushing a button and calling it a day.

Things will break.

And they will break in production.

So you can’t leave things be. You need to data driven and measure the Key Performance Indicators (KPIs) of every new version that you deploy.

Having enough data to do this is key. You want to have the most amount of metrics and conversion funnels parameterized into analytics events.

The required KPIs are different for every product, but here are five common ones that you should definitely keep in check:

1. User Acquisition: Counts how many new people download and start using the app.

2. Active Users (Daily/Monthly): Tracks how many people use the app every day or month.

3. User Retention Rate: Measures how many users keep coming back to the app after their first visit.

4. Average Revenue Per User: Calculates how much money, on average, each user brings to the app.

5. Session Length and Frequency: Looks at how long and how often users spend time on the app.

Going back to the priorities section, if you don’t have enough data to measure KPIs, fixing that should go straight to the top of your list.

Quality is first, and it needs to be measurable.

When thinking of how to improve the UX, asking the user what they need is the best.

But when making sure things don’t break, data is king.

7. Being an Owner means being a user

This is the last step, but it’s not the end — The Path of the Product Owner is a cycle.

The end is also the start. Which is asking ourselves what do our users need.

For this we can look at the raw data (KPIs). Or even better, we can reach out to our users and ask them, if our resources allow it.

But there’s an important alternative: You also need to become a user.

You cannot care about the pain points of your product if you don’t live through them.

So make sure that you’re using what you’re building.

Sounds like a no-brainer, but if you want to evolve from code monkey to Product Owner then it’s a crucial perspective that will feed back into the Product Ownership Cycle.

Now it’s your turn

The faster and more easily our thoughts become reality, the more powerful we are.

• Alex Hormozi

Start applying the knowledge from this post today and become a top notch developer in 2024.

By subscribing to the Newsletter, every week you will get in-depth knowledge directly to your inbox about each step of the Product Ownership Cycle.

See ya there!