Blog

November 30, 2016
From the Trenches: Setting Goals for Product Teams

Have you ever found it challenging to set and manage product goals? I’m often asked how I set goals and why. After working on product in both early stage and high growth startups, and at PayPal, a global corporation, I have a few thoughts on effective product goal-setting.

First things first: The Product Management function needs to be adapted to the business and people

There’s a reason why the product management function is different in each organization. Since the product organization aims to meet the needs of the business, it has to be adapted to it. So goal setting also needs to adapt to the business in order to deliver value. But don't forget the people. Since people have different working styles, goals also have to be adapted to the people on the team.

There’s no one-size-fits all approach to goal setting

There’s a reason why some companies have longer release cycles than others and that companies use either Kanban or Scrum as an agile methodology. There’s no one-size fits all approach. I sometimes hear founders say they invented their own agile methodology to serve their needs. Specifically, the type of company you’re in, and the kind of product you’re working on matter:

The size and growth stage of your company shape priorities and the goals that help you hit those priorities:

  • Are you in a global corporation? Unless you work within an innovation team, you’re probably looking at incremental % increase improvements. If you’re heading a department, you will care about how the goals align with those of the company. If you head teams, then you will care about how the goals align with those of the department.

  • Are you in a high-growth company? Then, you’re looking at generating hypotheses that can 10X your product adoption or revenue, with a healthy mix of “risky” and house-keeping goals. You’re willing to prune projects that don’t offer enough growth potential and you reward those who have well thought out hypotheses and execution regardless of whether they fail or succeed.

  • Are you at an early-stage startup? Then, you’re looking at product-market fit or traction. Your goals are customer driven, e.g. ‘at least 3 customers are adopting the new product X’ and so on.

The kind of product you’re building also shapes the kinds of goals that will matter the most to you and your teams. Here are 2 extreme cases:

  • Are you a web software company? Then optimizing the time-to-fix may make sense. Unless your industry is highly regulated, such as in the financial sector, errors are usually not critical. Your goals are experiment-driven and you ship new code often. A goal in that scenario could be: ‘do whatever it takes to increase user onboarding by 2X.’ Though you need to generate hypotheses of what may work. You don’t have to specify much detail because you’ll be experimenting a lot. Try lots of things and fail fast.

  • Are you a hardware company? Since errors in hardware are very costly, optimizing the time between failures may make sense. Since new features are introduced less frequently, such as quarterly, you want to be thoughtful about what the goals should be. In this case, your goals would be strategy-driven based on where the industry is headed as a whole and the level of commitments you’re getting among your customer base. Assuming you’ve done your product research beforehand, a goal could be: develop features X, Y, Z and make sure they are quality enough to make the release a success and drive customer satisfaction higher than W.

What about the time horizon for your goals? Basically how long you anticipate working toward goal A, B, C, etc. should match how often you release features (for example every 2 weeks for a typical scrum process) and how long of a time horizon it makes sense for you to plan for. For an early stage hardware startup, a 3-6 month horizon may make sense since making good quality hardware takes time. For a web software startup, monthly or quarterly goals may make sense depending how fast you want to adapt. Unless the web company is fairly large with known growth trajectories, 6 months would be an eternity.  Note that these are just examples and not guidelines.

Final word: Lots of things happen when you set goals. You don’t have all of the relevant information when you set them. So goals should be flexible and you should have a team process for revisiting them and fine tuning - they may need to change or be interpreted in a different way.

In my next blog post, I’ll talk about how to make your product organization accountable for their goals and what you can do when your team doesn’t always meet them.


Yvan Castilloux is an entrepreneur and former Director of Product at Jana.

Image via StartupStockPhotos.com