Long-Term vs Short-Term
Read on my website / Read time: 5 minutes
One of the most classic challenges for product managers is balancing the long-term vs. the short-term.
Innovation vs. existing product.
Strategic initiatives vs. short-term fixes and enhancements.
Here's an email I received recently that typifies this:
In case the screenshot is difficult to read...
“
I'm working on a brand new product that is a strategic initiative for our company. We are too early to know any revenue/cost saving impacts. And we are pre-launch so no early deployment emergencies. The emergencies have to do with borrowing engineers to solve pressing issues in other teams. I think the argument is the cost of delaying strategic new products that can fuel the future, but can’t quantify yet.
Any thoughts on how to make my case to protect this new product? These requests usually come to me from the C-suite."
There are 4 ways to tackle this situation:
- Retrospectively
- Operationally
- Strategically
- Entrepreneurially
Let's unpack each one.
Retrospectively
This type of conflict is very common at smaller companies, like an early startup or a small business. It's just a lack of resources.
At one startup where I was the head product executive, the founder always had ambitious plans for new products and innovations. However, the challenge was:
- The company was $5M struggling to get to $10M in revenue.
- We were spending $1.4M per quarter on product development on things like hardening existing capabilities, expanding use cases, and supporting legacy products.
- There was a constant stream of customer support issues and the platform was unreliable overall.
As you can imagine, emergencies popped up all the time. In a company of this size, losing even a $25,000 ARR customer is a big deal. So pulling engineers and product managers off their assignments and forming "tiger teams" to deal with crises was common (and necessary).
Bottom line: Although strategically the founder company wanted to do cool new stuff, and even put it into the company objectives, the reality was, despite spending 80%+ of revenue on R&D, there simply weren't enough resources to do cool new stuff while also supporting core product development needs AND quelling the constant stream of fires.
In this situation, the best we can do is to show the implications of these decisions after the fact - e.g., we planned to be at X by Y time on this initiative, but are at X-n because we had to pull resources, etc.
"At the beginning of the quarter, the agreed plan was to be to at 50% of our MVP build for Project A, with B and C capabilities built and D in progress. We had assigned 50% of a PM, 25% of a Designer, and 3 engineers for this. We're at 30%, because we had to pull those resources to deal with Fire X, Emergency Y, and Crisis Z.
Operationally
Instead of allocating fractions of people's time to the initiative, you could dedicate a set amount of the development capacity or fixed resources to the initiative. For example, 1 team that's 100% dedicated to the new initiative. You'd work this out in agreement with the CTO.
Pro: You have a committed workstream, undistracted from other priorities.
Risks:
- Doesn't entirely de-risk the emergency pull, especially at a smaller company.
- Can still be highjacked if not directly tied to strategic goals (AND those goals aren't grounded in reality, like in my story above).
- Executives - especially short-term ROI focused CFOs and impulsive CEOs/Founders - can run out of patience if they don't see tangible results soon.
Strategically
The above are resource-first, dev-oriented, operational type approaches. Most product management go there because that's familiar and comfortable.
More effective, however, is to make the initiative a true top-level strategic goal - a core part of the product strategy or a company OKR.
This forces the company to put its money where its mouth is. It forces the question: How committed are we to this thing?
We can then define it as a top-line product goal, identify a success metric, and associate it as a key initiative to achieve that goal.
By making it a strategic priority, it will have broad visibility, will likely get resourced, and will be tracked and reported on quarterly.
For example, here were the annual OKRs from one company I worked at:
Note the goals related to commercializing new products.
We used these corporate OKRs to identify top-level product goals and align key initiatives with them:
We were then able to strategically prioritize our roadmap toward these goals and key initiatives.
Here's another example from my course on product roadmapping, One Week Product Roadmap - based on another company where I led Product:
The top-line company goals were:
- 20% increase in revenue from the existing business, with 80% from existing customers vs 20% from new customers
- Improving customer satisfaction
- Entering California.
- Expand to a new vertical market.
We used these to identify the objectives for our product strategy and then allocate our roadmap to these objectives:
Note that the strategic goals still need to be grounded in reality. (That is, there have to actually be resources available in order to execute on the strategy!)
Entrepreneurially
Irrespective of any of the options above, the best approach that's guaranteed to work is pre-selling a customer.
Why? Because a committed customer gets the attention of the executive team every time. (Sales people are really good at this, by the way.)
Most product managers balk at this because:
- "It's too early. We don't know the revenue / financial impact."
- It feels like selling vaporware - something PMs are allergic to.
- It's not what they were taught by PM schools and agile training - i.e., discovery-build-launch-learn, continuous delivery, build-measure-learn, etc.
- It's way out of most PMs' comfort zone - it requires salesmanship and entrepreneurial gumption. You have to, in effect, be an intrapreneur.
The truth is, the best way to validate any product idea is to sell it before you build it. (Ash Maurya calls it Demo-Sell-Build.)
This is because customer currency is the ultimate currency.
That is, a committed customer who has bought or is ready to buy your product before it even exists because they're sold on its value proposition.
Some real-life examples - all of which I was a part of:
Example 1: Customer Pilot
A growth startup was interested in pursuing a Generative AI product opportunity that had massive potential.
Everyone was on board. Unfortunately, the Chief Product Officer was having a tough time getting it prioritized with the resources needed to make it happen.
The CPO learned there was a customer who was threatening to leave. They were super unhappy with their current level of service. After some investigation, the CPO realized that this customer would in fact be the ideal customer for the new product.
He got on a call with the customer and after acknowledging their complaints, pitched the new product idea. He pitched it as a co-development pilot.
Result: He won over the customer. The project immediately got funded, prioritized, and resourced. The pilot was successful and the customer provided a ringing testimonial for the product and the company.
"But, Shardul," I can hear you protesting, "I'm not a CPO!"
Ok, fine. Here are two more examples.
Example 2: Joint Venture
We had been unable to prioritize and get resources for a number of improvements to our product platform that we felt could both be new competitive differentiators and help us enter new markets.
Meanwhile, our company formed a joint venture with one of its enterprise customers. The JV was shopping around for a platform and put out an RFP.
My CTO, one of my senior PMs, and I teamed up to grab this opportunity. We were confident that the new capabilities we had been pitching for so long could also enable the JV to be successful.
Our calculus was simple: The JV could fund the new resources. We help make the JV successful while also being well positioned to go after those new market opportunities. Win-win-win.
We quickly put together a response to the RFP and created a quick demo and proposal for the JV executive committee. Our proposal included a budget ask for the additional resources.
Result: The JV Board approved our proposal over our competitors.
(Unfortunately, in the end, the project didn't happen because of a shift in strategic priorities for the JV itself. But the point of the story is our opportunistic and enterprising approach to solving the resourcing problem, which did, in fact, work.)
Example 3: Using Market Conditions
For years, we wanted to launch a tablet device based solution for an untapped use case in our market. The incremental revenue opportunity was very appetizing and it would have differentiated us in the market.
The project had struggled to get prioritized, though, for various reasons - more urgent priorities, lack of funding, lack of resources, no agreement on the scope, etc.
Despite our best efforts, it always stalled at the executive committee level.
When the COVID-19 pandemic hit, it opened a window for this product. We knew customers were looking for just this type of solution. Senior executives were scrambling for answers.
We quickly put together some conceptual mockups that we shared with a handful of account reps for key clients. That enabled us to get in front of those clients, to whom we presented a clickable prototype. This resulted in getting a number of pre-commitments - letters of intent, notes confirming interest, and even emails to our CEO asking for the product.
Result: The project got executive sponsorship, top prioritization on our roadmap, and dedicated development capacity.
In each of the examples above, I'm sure you can find reasons why they don't apply to you. I didn't say it's easy. Like I said earlier, the intrapreneurial route takes boldness, creativity, leadership, and gumption. But it's definitely doable.
Summary
Ultimately, we have to recognize that as product management we have no direct control (nor accountability) on engineering assignments. It's the CTO's call to assign engineers and they are well within their right to pull engineers to solve emergencies if that's what it takes.
That said, it's not like we're completely bereft of options. There are 4 approaches we can take.
And they're not mutually exclusive. Feel free to pursue two or more, if it makes sense.
Key Takeaway for This Week
If you're faced with this situation, think about how you'd approach it:
- Dedicate a certain amount of dev capacity?
- Make it a strategic objective - e.g., an OKR?
- Be enterprising and see if you can get customer currency?
If you want to get really serious about strategic roadmap prioritization and managing stakeholders, join an upcoming cohort for my masterclass on product roadmapping, One Week Product Roadmap. You'll learn how to get ahead of situations like this and craft a roadmap that aligns, inspires, and excites action - while making you look good!
