Summary

Reading time = 33 seconds (149 words)

When a squad is asked to deliver something out of the norm, we call these enterprise accelerations, oppty called shots, or solution called shots.

Oppty Called Shots differ from normal work only in that the oppty is not tied to the current “stable strategy”. The squad is asked to deliver an outcome, of the leading-indicator variety.

Solution Called Shots should be the most rare in an empowered product environment. The squad is asked to deliver an output.

Enterprise Acceleration is the most common and may resemble either an oppty or a solution called shot. The thing that makes them the most common is that the Why is always because of a technical partner, a current customer, or a prospect. I refer to them as accelerations, because you should really try to make them things you were going to prioritize soon, but the gravity of the partnership simply accelerated it.

You can stop reading here… below we simply will go into more detail on the above. Below is the mid-variant of this topic

[Min, Mid, Max] *

Reading Time: 5 minutes (1,375 words)

If you know much about my preferred product philosophy, you’ll know that I lean heavily towards the empowered team model.

In this model, execs/product leadership ask cross-functional squads to deliver outcomes, as opposed to output. These outcomes must be “Why-stacked”. Meaning, the “why” behind the outcome being given is as clear as possible.

Tangent: Stacking Why’s, or hypothesis chains, or opportunity solution trees are all trying to get at the same thing. Understanding, communicating, and being able to debug the “why” of everything we do.

Tangent off the tangent: I love 3’s… so of course I have a mental model for the variability of the altitude or surface area of the outcomes product leadership asks squads to deliver. I’ll write a note on the three levels (Impact, Lagging, and Leading) later.

Ok, if we are done with the tangents…

In the stack of Why’s, there should be consistency and strategy. However, there are times when a squad will be asked to make a detour and do something outside of the stack, chain, or tree. We call these Called Shots, and they come in 3 primary flavors.

Solution Called Shot

What

An enhancement that has been at least partially shaped

Why

Usually the Why is tangled web of expectations being unmet and maybe uncommunicated and product leadership decides the fastest way to untangle the mess is simply asking for a thing to be built.

When

This should be exceedingly rare in an empowered team environment. This should be seen as a smell. Either the product leadership needs to be better at delivering outcome-based missions, providing context, or maybe there is a cultural / trust issue and the team’s level of empowered is in question or in transition.

Oppty Called Shot

What

A leading indicator outcome. Very, very similar to what empowered product teams are tasked with. The only difference is that these are not tied to the current “stable strategy”… meaning they could feel s if they are coming out of no where.

Why

Similar to solution called shots, usually the Why is tangled web of expectations being unmet and maybe uncommunicated and product leadership decides the fastest way to untangle the mess is simply asking for an opportunity to be prioritized.

When

Though these should be rare, they actually fit relatively nicely in an empowered team environment. Especially depending on the outcome-altitude your environment and/or squad is used to.

Tangent-part-1-of-3: If you are used to Impact measures (multi-faceted and lagging, such as gross retention or NPS)… then these will feel like a big swing from the norm. However, squads tasked with only Impact measures will inevitably have other issues, so I discourage this.

Tangent-part-2-of-2: If you are used to Lagging measures (these are usually domain specific product engagement measures that are the result of many different actions being taken)… then these will feel like a big swing from the norm. However, similarly to Impact measures, I discourage squads being tasked with exclusively delivering lagging indicators.

Tangent-part-3-of-3: If you are used to Leading measures (these are usually domain specific product engagement measures that are the result of one or very few and very related actions being taken)… then these will feel like the norm.

Tangent-series-takeaways: My preferred style of empowered product team is to make the Impact measures very visible. To let folks know that these are measures that the entire company is accountable for. They are too multi-faceted to be handed to a single group. Then have lagging measures be the prime directives of the squads. Then have three variants of leading indicators, based on time-investment: 18-month, 18-week, and 18-day levels. Product leadership should be setting the 18-month (working closely with the squad). The 18-week variant should be heavily guided by product leadership, but in some environments this is requested of the squads (must have incredibly tight calibration between product leadership and the squad for this to work well). The 18-day variant should be squad-exclusive.

So the level of rarity depends mainly on the factors that are leading to the need. It could be a small cultural / trust issue, the team’s level of empowered is in question, or in transition. It could also be a 🤷🏾‍♂️ shit-happens scenario. Usually, a “shit happens” scenario. As much as we like to reduce context switching and staying focused, the world, the market, our customers don’t care about that stuff and sometimes we have to adjust to these needs. Not all of the time… but if we don’t have room for it, we will be disappointed.

Enterprise Acceleration

What

In a SMB world, no customer has enough pull to force a product team to change their plans. The ARR per customer is too low. However, when you get into mid-market and enterprise, the gravity of those individual deals take a different shape. The specific requests can’t be exclusively ignored.

So what do you do with these? Ideally, you convert them into outcomes… make the outcome something that is applicable to a vast majority of your customers, and “accelerate” that oppty.

This is incredibly different from hearing a want and doing that specific thing for that specific customer.

One can be healthy… while the other is a recipe for disaster.

⚠️☣️WARNING☣️⚠️ This is worth repeating. If you find yourself needing a consistent percentage of your calories spent on enterprise accelerations, you may have some very big issues. The issues that come from being essentially a consultant to a few customers have been written about a ton, and I may write something on it myself. But suffice to say… this is a major, major, major issue that will very likely lead to a bad place.

Why

A technical partner or a high-ARR customer has a need. The need is one that product leadership has deemed worth the distraction from the stable strategy.

When

If it isn’t clear… all called shots should be rare… enterprise accelerations included. As the warning says above, if you are constantly doing these… then you either:

Need help translating requests to opportunities
Have an environment that embraces being a SaaS consultancy, and you are ok with the tradeoffs that come with that (or are desperate enough to accept the debt of doing this)
Have a need for a new squad with a Prime Directive around the continuous needs

Regardless… if this happens every quarter… you need to go see a Product doctor to help you diagnose the issue!

One more thing about enterprise accelerations: As always with called shots/enterprise accelerations we will be on the lookout for two things:

(1) If the enhancement could benefit others…

… We should always as ourselves how can we build it such that it is generalized enough that others could realize the benefit? We are not a consultancy, and taking on debt to do one thing for this one customer is a debt that I can personally guarantee you is going to cost way more than you think it will.

(2) If that path is not clear or the cost/benefit is out of whack, then we look for the absolute smallest thing possible to meet the enterprise need.

Often with enterprise accelerations the need is based on bureaucracy (compliance or some sort of standard operating procedure). So we have to dig to find “value”. Such as enterprise accelerations. Which makes our path forward opaque. However, once we excavate the actual need… often there is a small bit of debt we can accrue to resolve it. This is NOT normal SaaS product work. This is consultant work, and consultant work that must not harm the actual SaaS product work we must still do.

So either look for the oppty that is applicable broadly or look for the absolute smallest/least-intrusive/cheapest-to-maintain thing possible!

Regardless of the variant… You hope that each of these are reviewed and we learn from them. How they came to be is understood. Understood so that the underlying systems can be adjusted to try and reduce them in the future.

But, they are inevitable, and should not be treated as a surprise when they arise. They should be treated like any other unexpected exception to empowerment… as a learning experience.

I’m not sure a max-variant is necessary, mainly because I think the clarity comes in the links to what the three types of called shots.