Wrong goals and targets can be damaging for early-stage products

I was tasked with starting a "big bets" team at a startup I was working at. The goal of the team was loosely defined as to achieve step-level or 10X outcomes -- either in the core job-to-be-done or through a new job-to-be-done. 

I was previously leading growth for the core product and I set this team's key performance indicator (KPI) or key result (KR in OKR) similarly -- X monthly active users. 

And that was a mistake. 

Done right, a KPI is a measure of the most important thing, provides directional guidance, and is a measure of progress. A wrong KPI can be useless, misleading, and demotivating. 

For a new product area, the most important thing is to identify the problem space to play in and to achieve product-market fit. The goal of X monthly active users is a big step removed from that. It didn't provide us directional guidance, didn't provide a measure of progress to either the team or the execs, and it felt pretty demotivating to declare failure against that measure every quarter. Yes, eventually what we build would need engaged users and revenue, but that's pretty unhelpful as a KPI at that early stage. 

KPIs for early-stage products are a bit mushier. I'd prefer a checklist of inputs and KRs around making progress on it, rather than numerical measures. For example: 

  • Have we aligned with the team and execs on the approach, timeline, KPIs, and a way to check in on progress?
  • Have we identified and understood promising problem areas?
  • Have we developed confidence in the problem areas?
  • Have we identified and prototyped solutions?
  • Do prototypes show promise?
  • Are we ready to double down now or should we explore further? 

Rahul Vora, co-founder of Superhuman, has shared one of the most robust frameworks for getting to and measuring product-market fit. You may be able to define KRs and outcomes using that framework (score of X for "how would you feel if you could no longer use the product" for a segment Y, with sufficient TAM)

Some teams and execs feel compelled to use numerical goals and sometimes fall back to measuring inputs like the number of prototype iterations or user interviews, but you have to be very careful with those as that can direct people to do busy, but ineffective work (Goodhart's law - when a measure becomes a target, it ceases to be useful). Bad measures, especially with early-stage teams, can be damaging. 

It's also hard to commit to a specific timeline for outcomes as the timeline to product-market fit is unpredictable and can sometimes take years, even with the most capable team. But you can have timelines around inputs, as long as you keep it short-term and flexible.

So if you are an exec or manager, you are largely relying on your PM and team to do their best attempt, without much visibility or measure on progress. So you'll have to give this responsibility to a trusted, capable, and innately motivated team that can communicate well. You'll have to reward them based on the quality of inputs, rather than on business outcome or impact as these are high-risk bets. 

I think this philosophy applies to personal life too. When you are starting on a new routine or hobby, say exercise, people often rush to set a goal to exercise X days of doing Y a week. They often fail at it, feel guilty or defeated, and give up. Instead, your initial goal should be to find a routine<>person fit first by exploring and iterating before you decide to operationalize and scale the routine.