We are All Product Owners! An Impact Guide for Engineers*

* and everyone else

I used to work for a company that valued shipping. I use shipping loosely — it means going through a checklist of things that defined my job. My compensation and advancement were not tied to how well the product did in the market nor my impact for the company. As long as I shipped on time, I was doing well.

I then worked at a company that focused on impact. It didn’t matter much what I shipped or when I shipped it, so long as it had impact on the business. I was rated every 6 months, which meant I needed to have real, measurable impact during those 6 months.

Think for a second about the implications of this:

At the ship company, a project could take 3 years, while I kept advancing.

At the impact company, I didn’t advance if I didn’t have meaningful impact for a year.

At the ship company, QA’s role was to stop engineering from shipping something that was clearly broken.

At the impact company, QA’s role was to work with engineering to make sure the right features work well.

At the ship company, release dates were sacred.

At the impact company, we shipped when we thought the product was good enough to have positive impact on users.

The ship company was a fortune 500 company. It doesn’t exist anymore.

The impact company is here and doing very well.

What is Impact?

The obvious answer is business impact. Making more money for the company, saving money, increasing the number of customers, the number of transactions, reducing the cost of support, etc. Focus on the company’s top goals.

There are a lot of other ways to impact the company, so long as they tie to those goals:

Not everything is measurable.

Fixing a bunch of UI glitches that impact a specific feature won’t be easily measurable, but it does increase overall brand sentiment and the enjoyment users have from your service. In the long term it’ll impact net promoter score.

Removing tech debt, or making systems more reliable is not always measurable. It’s still critical and impactful since your development speed will slow down if you don’t make the system easy to extend. The art is in picking things that will actually help, not refactoring to a ‘cool new technology’.

Doing code reviews helps your team get better by teaching others new things about the code, while driving for a high quality bar.

If you think it’s important and don’t know how to measure it, talk with your manager or your peers. See if they understand the value of doing it at this time. They might also have a suggestion for how to measure the impact.

While not everything is measurable, you should cultivate a bias towards measuring.

Why a Bias toward Measuring?

Consider the following statements that typically show up in people’s self reviews:

These are checklist items. They are ways you can have impact, but not the actual impact you have.

Now consider these examples:

It is very clear why these projects had impact for the company. They either increased a business metric, saved time and freed up people to work on other things, or in general improved the company.

But I’m not the PM!

Engineering and product management should be aligned on building the right products with minimum effort. Engineers look at the product every day, we read the code, and we go through the process of deploying and changing and fixing. Impactful things don’t have to be new products. They can be UI fixes, more stable systems, things that make it easier to use the product. For example, identifying critical actions that are below the fold on mobile devices, or improving a login funnel to transition people directly into an abandoned checkout flow, could have large impact on the company’s key metrics. These are all things engineers can identify, communicate and drive.

How to Think about Impact

Think about impact in what your company values:

Without thinking about the impact you’re having, you might just be wasting your and other people’s time.

Thinking about impact throughout the product creation process takes different forms.

During Ideation

During Planning

During Execution

During Launch / Testing / Monitoring

Isn’t This Rewarding Luck?

Consider what your company’s performance reviews emphasize. Do you get rewarded for motion (shipping), or for progress (impact)?

The goal is to reward people who make good decisions. Some luck is involved in everything we do, but think about the following two people’s performance over 3 consecutive performance review cycles.

The Engineer’s Engineer:

Term A: Great planning, project didn’t pan out.

Term B: Great coding skills, projects had minimal impact.

Term C: Architect-level thinking about the system, caused 4 teams to have to rewrite their interfaces. A way to make the current system better was discarded since it wasn’t cool enough.

The “Lucky” Engineer:

Term A: Ran lots of short-term experiments, 10% increase to Widget Production.

Term B: Reworked the site’s design, 5% reduction in abandoned carts.

Term C: Refactored backend stack, page load time decreased by 20% driving 5% decrease in bounce rate.

No one is THAT lucky. The “Lucky” engineer is making some smart choices. She’s picking the right projects, she’s finding ways to verify if something is worth doing, she’s evaluating work with the end result in mind.

The Engineer’s Engineer is wasting some amazing technical capabilities on the wrong things.

Do you Promote a Short Term View? What about Long Term Projects?

I’m promoting a balanced approach with a preference for short term. If you start with a long term approach, you’ll have lots of things that might be great next year, but the company might not be around long enough to see them realized. If you start with a short term focus, you then find ways to accelerate projects, to refine your MVP, to very quickly identify a wrong path and terminate it. Companies should define a mix of long, medium, and short-term bets. One mix could be 70% of projects with impact within 6 months, 20% within 1 year, and 10% longer term. Calibrate to your situation and your industry, and evaluate based on the product’s and company’s life cycle.

As for long-term projects, do them well! Sometimes you need to create a new database because you can see that your infra will fall over in a year. Sometimes you need to research a new technology that will unlock new product opportunities and business lines. Think about the following:

  1. Is this critical for the business? In what terms? Can you convince others working with you that this is more important than other things on your plate right now?
  2. Is there a simpler, shorter, maybe less cool way to achieve what you’re doing?
  3. Is there a way to quickly test the hypothesis before building the entire system? The last thing you want is to work for a year on a new ML infrastructure and train it on people’s preferences, only to discover that those don’t drive sales.
  4. Will the rest of the company keep using the ‘legacy’ technology and improving it, to the point that when you’re done with the new technology, you’ll have two well-functioning systems that now compete? Maybe incrementality is better and less disruptive than the new shiny thing?
  5. Will the impact of a big project be proportional to the time it takes? If not, why is it worth doing?

If you decide to pursue a project, set clear milestones and make sure you’re making real progress towards each, not just “still working on it”. Keep asking — does this still make sense?

Does This Mean You Punish Failure?

Our definition of failure might differ:

I don’t punish failure. I reward taking risk and success. Making the right choices and executing well will give you a much higher chance of success.

P.S. Which companies was I talking about?

Most companies don’t fail for just one reason. The “ship” company had other issues that caused it to eventually be sold off. The impact company is Facebook. My current company, Lyft, is pursuing impact.

Head of Engineering @ Sigma Computing, ex-Lyft, ex-Facebook and startup founder.

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store