Strong Product Ownership in Engineering

Authors: Nino Aquinas, Hilfi Alkaff

Consider a typical product development cycle in a tech company.

In a team where there is a product manager and engineer, the above responsibility is typically split in the following way:

Product Manager

• Typically owns “Finding The Problem” (1) and “Prioritizing the Solution” (2).
• The output of the process is usually in the form of a Product Spec (or PRD, etc) which is then passed on to engineer.
• Let’s call this process “building the right thing”.

Software Engineer

• Typically owns “Designing the Solution” (3) and “Deliver the Product” (4).
• Engineers may work closely with designer(s) if the project is more UI heavy.
• The process usually is more “technical” and focuses a lot more on the execution. The output of (3) is often in the form of design documents while the output of (4) obviously is the final product itself.
• Let’s call this process “building the thing right”.

Having a strong product ownership as an engineer essentially means:

Your role isn’t only about “building the thing right”.
It’s also about “building the right thing”.

Why

Focusing on building the right thing matters since if you don’t build the right thing, your project won’t ever succeed no matter how flawless the execution is. There is — however — a lot of not so obvious negative side-effect of an engineer who only cares about building the thing right. These are some of the common ones we have observed:

It reduces the sense of collaboration/teamwork between team members

• This mindset usually encourage “I” vs “Them” mentality, where engineer draws boundaries between what their responsibility is vs what the PM/other side responsibility is. This is especially bad for startup since startup tend to have a smaller team so it’s really important for everyone to feel that they’re in the same team at all times.
• Lower collaboration means fewer ideas being generated which leads to fewer project that actually “work”.

It makes the engineer reactive instead of proactive

• An engineer with this mindset usually find it hard to adapt to requirement changes in the middle of the project and get demoralized whenever it happens. The truth is that the ability to be able to change the requirement of the project as we learn new things about the user and the market should be the strength of a small company/startup vs a big one.

It leads to more bugs

• This type of mindset doesn’t encourage the engineer to fill in the whitespace — a space that is not explicitly mentioned on the product spec — but should be obvious if the engineer care enough about delivering successful product.
• More bugs leads to more technical debts over time which will slow down future execution.

It slows down product delivery time

• An engineer that just work on whatever requirement is given to them might think that they’re using their time really productively — since after all they don’t need to have the back and forth conversation with the PM, business development team or designer who come up with their product.
• In reality, the opposite usually happens — when an engineer doesn’t get proactive in asking deeper question on the motive of the project, often times the engineer wasn’t fully aware of different type of adjustment that they could make on the spec that could cut down development time by a lot while only sacrificing a little bit of product feature.

Last, and arguably most importantly, it limits engineer’s growth rate

• Engineer will be less motivated in understanding what makes their product works — which further hinder their progress in building intuition to implement their next successful project.
• Engineer will be less likely to learn about different opportunity in the company. Working on a product spec alone will make it hard for an engineer to get a bigger picture of what the next highest impactful project within the company.
• Engineer will be less critical on their scoping and technical stack understanding.

The Mindset Shift

Having a strong sense of product ownership requires a fundamental mindset shift on how you viewed your role as an engineer. Changing mindset can be hard and daunting, especially since it’s not easy to measure your own progress while you’re in it.

One good starting point though is to ensure that as an engineer you’re always aware on the importance of your project, the company goals and how these two are connected. Concretely, this is the set of questions that you need to know the answer of and agree with, before you start working on a project.

1. What are some of the most important goals of the company now?
2. Why is my project prioritized over other projects that we could have done instead?
3. How exactly the outcome that my project needs to deliver to affect the company goals?

These seemingly basic questions often times will have a non-straight forward answer that requires a lot of product context and business understanding. Hence, the act of asking yourself this questions and seeking for an answer will inevitably leads you towards being more proactive in your product thinking. Having said that, you’ll run into some of the below scenarios in your quest of answering these questions:

You don’t know the answer on some of the questions.

• This is very normal. Use your 1:1 with your manager or schedule sometime with your project lead and ask them the question. Make sure that you understand their answer and agree with it.
• Another remember, the more context you have here — the less likely you’ll put yourself in position to avoid all the mistakes mentioned above. So when in doubt, always lean towards over-“asking”.

You know the answer to the questions but disagree with the answer itself.

• This usually happens when you don’t have full context on how the decision are being made. In this case, you want to first communicate why you disagree with the current decision and ask for full context from your project lead / manager. One or two things typically will happen here, your manager lack the context that you have and will adjust the plan accordingly, or you lack the context your manager have and comes to agreement on the right set of project.
• There will be times where the company have to make a bet and some people will have different opinion on which bet to take. This is very normal in a startup and the most productive course of actions to choose one bet, execute and fail as quickly as possibly if the bet doesn’t pan out.

You know the answer to all of the questions and they makes sense.

• This is great! Well done, now you can focus on making sure that you execute perfectly 😉

In this post, we try to cover what does it mean to have a strong product ownership, its importance and how to build a product ownership mindset. That said, product ownership in engineering might look a little differently in different companies depending on the size, culture and industry. Let us know how product contribution from engineering looks like in your company!