“We need this to roll-out the product uncomfortably slowly”. Those words came from the Citrix CFO, as our new skunk-works product team eagerly awaited to “go big” with our business-changing product. It felt very odd that in the high-tech environment, this would be our guidance. Go slow?
But the recommendation… worked. We’ll talk more on this later.
Since then, I’ve found that this guidance, when applied judiciously with new ventures and with new products, is invaluable.
Briefly, it implies that one should always pause and consider:
- When to seek product/market fit, vs.
- When to seek growth, vs.
- When to seek scale.
As Michael Seibel, Managing Director and Group Partner at Y Combinator, said, “Scaling [before] market fit is the number 1 killer of startups – in other words, the fastest path for your investment to be worth nothing”.
Yep, getting ahead of yourself will spell disaster.
Act I: The setup
Around 2009, I was running a chunk of core product marketing at Citrix Systems. The company was in the business of selling complex virtual desktop software using perpetual (term-limited) licenses – to the tune of over $1b annually.
It was also the beginning of the cloud-computing trend, and our CEO chartered our GM to create a small skunk-works team to investigate how Citrix should respond.
By the way, we knew we faced the classic Innovator’s Dilemma – knowing we had to replace/cannibalize our own product with something new before the competition did.
Our team consisted of our GM, Product Manager, Engineer, Designer, Business Lead, and Product Marketing Lead (me). And a completely blank whiteboard.
It took us close to a year to assess the market, compare existing products, run focus groups (led by our designer) of customers and non-customers alike, and finally to propose three options back to our executives. After feedback and even more focus groups, we arrived at an architecture and then an MVP.
The beta rollout worked pretty well – with largely positive feedback from a carefully selected handful of existing customers. Our excitement was high, and we were eager to announce the company’s shift from clunky software to an elegant, cloud-based platform with simple subscription pricing. How soon could we tell sales? When could we engage marketing teams? Tell the analysts? How soon could we “Go Big”?
The GM and product manager went to our CFO and CEO for guidance.
Act II: What we were told to do, and why
“We need to roll-out the product uncomfortably slowly” was the message the team got back.
At first, we were a bit shocked. How could we possibly be told to wait? The market could pass us by! Shifting to a subscription could increase our market valuation. The analysts would rate us even higher.
Why wait?
The feedback details became clear very quickly:
Pricing immaturity
We hadn’t tested the pricing in all circumstances, and didn’t fully understand whether it was too high, or whether we were leaving money on the table. And there was no model for existing customers to shift from perpetual licensing to subscription.
Product maturity
We knew it had “rough edges” and the potential for performance issues at scale. So jumping into the deep-end at scale could be risky. Better to roll-out in a controlled fashion so we could identify bugs and scale problems.
Don’t create sales disruptions
With this new model, how should sales be trained? Should certain customers who were comfortable with software continue with the old model? When should customers be told to migrate? And most of all, how would sales commissions and incentives now be calculated?
Don’t upset the pipeline
With a $1b sales pipeline (and with the public markets understanding how it impacted our earnings multiple) changing the sales and revenue model too quickly could lead to disruption, defection, or competitive losses.
Customer targeting data
We couldn’t be sure what segments of existing customers would want this new technology. Or, which segments of new customers would, either.
Customer messaging feedback
The wrong messaging and education could potentially cause customers to get “spooked” about which product to use, or not to use Citrix at all.
Act III: What we did, what we learned
Once we digested the sobering feedback, we put together a year-long mindful rollout plan. It would initially include “white-glove” invite-only customers, and then to a very narrow set of use-cases and pricing that would only appeal to a special fraction of existing customers. All-the-while, we carefully helped migration, implementation, and use metrics… we were still in a learning mode.
Slowly over the next year we made pricing (and functionality) more appealing to broader segments of the Citrix customer base. And eventually, to net-new customers as well.
What did we learn in this process?
- Adoption: It can take a year for larger customers to learn about new approaches, and become comfortable with new products.
- Pricing: It took nearly a year for us to understand pricing, given so many variables, migration use-cases, localizations, etc. not to mention finding ways to justify shifting from software ownership (and support programs) to all-in-one subscriptions.
- Product releases: The company product teams had to learn to shift from large software releases, to continuous development and release – how we now understand SaaS.
- Scale: Learning to scale a global SaaS product wasn’t easy!
- Internal education: We had a massive internal change-management program, to educate sales in subscriptions, marketing in messaging, customer success in growth, legal in contracts, and so much more.
Fortunately, it became very clear that taking the time to get these (and more) items right, saved us immeasurable time, avoided the embarrassment of poor product quality, and grew the business rather than scaring-off more conservative customers.
Act IV: What this story means to startup marketing, MVPs, new products, and more
Even though this story took place at a huge B2B company with existing products, I learned that introducing any new product requires a thoughtful approach:
- No matter the size of your product or size of market, approach the initial introduction narrowly! Test your messaging, assess customer usage, examine pricing, measure feature use, assess onboarding – all before rushing into the scale phase. Beta programs are great for this.
- Putting an MVP into an existing market requires proper expectation-setting – inside the company as well as with customers. Help both audiences understand short- and long-term impacts. Will it change the business, and if so, how? Will customers need to migrate? Will it change their use patterns? Their payment patterns?
- Don’t make assumptions about buyers, messages, functionality, etc. – Always look to your customers for data, research, and validation! (What you think your product should be, isn’t necessarily how your customers will perceive it.)
- When it’s time, plan for growth. Meaning, ensure that you have the (technical and support) capacity to scale. Worse than having too few customers, is putting a product in the market that underperforms and causes customers to be disappointed and defect/churn.
- Take time to educate customers and markets – when introducing something new, even in tech – don’t assume your buyers understand it. Seek the early adopters, look for adoption barriers, and recognize that they may not be your mainstream customers.
- Finally: Learn fast, fail fast… run experiments and quickly determine if the outcomes are positive or not.
