So you’ve probably heard of “earlyvangelists”.
(No? Read this post by Steve Blank, who coined the term.)
In Lean Startup circles, we hear a lot about finding these special breed of customers. Why? Because they’re the ones willing to make the initial bet on the startup, because they’ve bought into the startup’s vision and potential. They’re not just buying release 1, but the entire vision of the startup. This is what keeps them committed even if the startup screws up a few times.
They are the true visionary customers talked about in the technology adoption lifecycle.
So a lot of focus is put in identifying, finding and nurturing these earlyvangelists. Test customer and problem hypotheses. Test solution hypotheses. Create an MVP. Find problem/solution fit. Get true customer validation by finding a handful of customers who are actually willing to pay you for your solution — the “earlyvangelists”.
Juxtapose this with traditional product management.
Now, when I started out in product management, I was indeed introduced to the technology adoption lifecycle. I read about it in books. People talked about it in conferences. “You must find those visionary customers and early adopters,” experts said in their presentations. Cool.
Problem was: no one taught me how to get these magical customers.
Instead, what I was told was to develop a business case. Write an MRD. Create a business plan.
Business school told me I was supposed to do this. Smart consultants and well meaning senior executives and mentors reinforced this. Elaborate PMO processes required this.
Want resources for your product idea? Show us your business case.
So what’s wrong with that? On the surface, it made sense. Unlike a startup, which is searching for a sustainable business model, a company is executing an existing business model.
Shareholder returns, customer value, and employee paychecks depend on the successful execution of this business model.
So the company needs to evaluate its investments in terms of risk to this business model. A company needs to know whether to dedicate its resources to project A or B. To do that, it needs to know which has the better payoff.
For example, the CFO needs to be able to answer a question from the Board like, “That $250,000 in development resources you spent last year… what are we getting for that?”
So a solid business case with cost/benefit, ROI analysis, risk profile assessment, etc., would allow for objective portfolio and investment decision making.
But here’s what actually happened.
Product managers began spending loads of time crafting multi-page MRDs and business case slideware, and crunching through multi-year financial “projections”. These documents were filled with unvalidated assumptions or HiPPO driven convictions.
“An exercise in pretend,” the product manager grumbled.
“How the heck can I figure out whether customers will buy the product before it even exists?” they’d ask. “And how can I figure out how much money it will make when no customer has bought it yet?”
“Well, you need to figure it out,” Big Exec would shoot back. “Else, no resources for you!”
And so the product manager would torture the spreadsheet more, try and convince finance of adoption rates and growth trajectories based on mere guesses, and go to Engineering/IT for estimates.
“You need to give me requirements,” Engineering/IT would say. “If they’re not documented, there’s no way I can give you estimates.”
So the product manager would then start writing an MRD / PRD / BRD / <stick your 3-letter acronym here>. Ah, the joy…
And under pressure to get “accurate” estimates, they’d pack in as much detail as possible, essentially guessing at the features and functionality that would be needed.
(Meanwhile, that Sales guy with his own “great” product idea has already sold vaporware to two customers and is magically getting resources assigned to deliver on his promise, including you, the product manager. Sales guy: hero. Product Manager: zero.)
The saddest part of all this was that every minute spent preparing the business case, writing the MRD/PRD or torturing the spreadsheet was valuable time not spent with customers.
So it’s no surprise that in a recent survey filled out by over 40 product managers who opted into my upcoming online course, Idea To Revenue Masterclass, they listed the following as their biggest product innovation and planning challenges:
#1 Biggest Innovation Challenge: Testing product ideas without having a product. With both customers and internally within their organizations. They need ways to test their understanding of the market, as well as evaluate the revenue potential for a product opportunity, but without having a product already.
“My number one product management challenge is creating business requirement documents on new products and demonstrating a return on investment for 1/3/5 years without releasing the product.” – survey response
How many people does it take to change a light bulb?
(Or maybe the question is: how many people does it take to get approval to change the light bulb?)
This challenge is a close second to #1 above. Product innovators are challenged with communicating product strategy to get buy-in, getting executive support for their product plans, aligning teams within the company to support new products, and managing communicating across multiple stakeholders.
“In a growing organization, with lots of ‘people of interest’, communicating what you are building and why is a huge challenge.” – survey response
The internal venture must fight on a second front at the same time within the corporation. That second fight must obtain the permissions, protection, resources, etc. needed to launch the venture initiative, and then must work to retain that support over time as conflicts arise (which they will).
– Henry Chesbrough, Why Internal Ventures are Different from External Startups
#3 Biggest Innovation Challenge: Resources.
We can never have too many resources, can we?
Working with resource constraints is a fact of life. But product innovators feel this acutely so.
They’re pushed to accelerate time to market, yet are challenged with selling the business case for the right mix of resources to do just that.
And, of course, this leads to the chicken-or-egg dilemma from challenge #1 — need a product to test whether customers value it, but need customer validation in order to get the resources to build the product!
“[My #1 product planning challenge is] getting and retaining key resources to minimize time to market consistent and aligned with company priorities.” — survey response
So what’s the solution?
This brings us back to “earlyvangelists”…
Lean practices can and should be adopted and adapted to pursue product innovation inside companies. But product innovators actually need to find two types of earlyvangelists:
- Earlyvangelist customers.
- Internal stakeholder advocates, or “internalvangelists”.
One of the biggest factors that can derail any new product endeavor is lack of internal support. In product innovation, lack of stakeholder traction can often be a bigger roadblock than customer traction.
These stakeholders may not only have access to essential information and resources you may need, but also influence key decision makers whose support is critical to the success of your product initiative.
The larger the organization you work in, the more stakeholders you’re likely to have. It’s important to identify who these folks are and make sure you’re not only bringing them along, but in fact creating them into advocates — evangelists — for your product initiative.
The good news is a lean approach that fuses customer development type methods with sound product management practices can be used to not only get early customers, but also build the business case, create alignment, and cultivate internalvangelists iteratively.
Here’s an example:
The approach calls for spending plenty of time with customers in a methodical way, systematically testing assumptions at each phase, while also having regular check-ins with folks internally.
Each stage is informed by learnings from the previous stage — “mini business cases”, if you will, at each milestone, instead of wasting time writing a big tome of a business case up front.
Requirements for delivery need only be done when there’s a clear signal to do so. For example, if you find there’s no problem/solution fit, no need to write detailed requirements to build out an MVP or do financial projections. But if there is, then only does it make sense to spend the time doing those activities.
This customer learning driven approach makes for a more market-informed investment approach to the product strategy. This makes it easier to garner, maintain and accelerate stakeholder buy-in, because:
(1) Each investment stage is grounded in real customer data, resulting in less assumptive and more empirically based investment asks.
(2) Smaller continual investments that deliver continuous tangible ROI throughout the process are easier for folks to digest and support than large bloated ones upfront.
(3) Stakeholders continually feel involved in the process, increasing confidence to persevere.
There are surely other variants to this approach. The point here is that lean principles can be fused with sound product management practices to:
- Test product ideas without a product.
- Build the business case iteratively.
- Get alignment and buy-in, and create internalvangelists.
- And get those magical earlyvangelists!