First off, a huge thank-you for all of your writeups. I’ve learned so much from you over the years Jason.
Q: What was your most productive strategy for getting entire development teams to adopt Code Collaborator?
I’m particularly interested in your observations of getting your foot in the door with engineering teams that typically tend to be of the mindset 1) I could build this myself and 2) I don’t want to be directly approached/sold to.
Thanks again for everything.
Thank you for the kind words!
How to get entire dev teams to use a tool
This is going back more than 15 years, so let me caveat by saying that the world has changed since then, so even if I know the answer exactly – which I can’t, because it can be hard to explain the causes of effects – it still might not be relevant today.
The good news about Code Collaborator is that the entire point is to use it with others – for code reviews. Therefore it’s naturally viral, like version control, and unlike CI/CD or an IDE. Therefore, the strategy was simple – have some champion bring it in, and if people like it, the whole team naturally adopts it. After that, another simple question, asked occasionally: Who else at the company do you think should use this? Would you intro us to them? (Because an internal referral is 100x more effective than a random cold email saying “someone else at your company is using this.”)
I would think all that would work today. But also this is fairly obvious nowadays, where there’s tons of advice that you should make viral products. Better, we now have developing theories of PLG (Product Led Growth), with emerging “best practices” (or just widely repeated advice?) on how to do this systematically, and with other kinds of products, and in conjunction with a sales team, and so on.
Furthermore, thanks to the Consumerization of the Enterprise, both individual employees and whole departments are more accustomed to a tool being used or piloted in one place, then sometimes making it to other teams or the whole department. So the road is now paved, sort of like how Salesforce paved the road for all other SaaS by getting Enterprise companies comfortable with putting sensitive data (customer lists) in “the cloud.”
So I would follow the new “rules” of PLG: The customer is in the driver’s seat, getting value first and paying later, self-serving things like documentation, deciding when they want interaction, whether support or sales, but also often becomes more than a user but an advocate, eventually helping you to sell when that time comes.
Hey Jason, thank you for doing this AMA. I appreciate your thoughtful and detailed responses!
A typical playbook I’ve seen VC-backed SaaS companies adopt is to start with low pricing in the early days and then eventually raise prices, go upmarket and price out the SMB / early-adopter segment. I’ve personally experienced this as a customer a couple of times in the past.
There seem to be a few exceptions to this playbook and WP Engine seems to be one of the exceptions that still serves the SMB market well, in addition to enterprises. (I can may be think of Shopify and FreshService as other examples).
What would you say are some good counter-arguments to balance the allure / pressure of growing revenue quickly by going upmarket vs truly serving the SMB market for the long-term?
What is the argument for staying with SMB while going up-market?
I think more and more, companies are staying with SMB too. I could list many examples: Hubspot, Slack, ZenDesk, Github, Gitlab, all cloud platforms, and not only WP Engine but all our direct competitors.
The reason to leave SMB behind is ARR growth and margin expansion, and sometimes fewer competitors. All of those are good strategic reasons, so the company’s aren’t necessarily wrong for shifting their attention. It’s also hard to maintain a product that serves many customer segments – not impossible, but hard – so it’s also a good strategy to not tackle that particular problem, and stay focussed on a segment, even if that segment changes.
However, there’s lots of advice from solid pundits and investors online, who say you should never give up the SMB market. Jason Lemkin comes to mind immediately. Why is this a good strategy?
One major one is that SMB is where the “N” is. N has a lot of benefits – attention, lots of users. Lots of users means lots of feedback. It means people are constantly changing jobs and maybe taking your software into the new job. There’s a lot of data, which means you can detect subtle things, which means your optimization or customer dynamics can be more data-driven.
Another is going global – there’s even more SMB vs ENT outside of the USA, and even more outside of Europe. The best way to grow in India is not to go upmarket.
Another is that it keeps your operations efficient; low prices means your service and infrastructure need to be efficient. With ENT, that translates to even higher margins. A counter-point is that you’re not built for the needs of ENT, but at least you’re keeping your baseline low, which can lead to higher margins than competitors who feel they can burn margin to win higher ARPU.
Another is that SMB and ENT growth can be uncorrelated, because the market forces are different, and the reasons people buy the software might be different. As an example, WP Engine at its lowest price is still 10x more expensive than a commodity shared host, therefore for SMB WP Engine has the “differentiated best” competitive strategy (using Michael Porter’s language). Whereas in the Enterprise, where the main website is probably on Adobe Experience Manager or something else that costs millions / year to develop and maintain, WP Engine’s expensive plans are the inexpensive option, so we’re the “low-cost leader” using Porter’s language. So it might make sense that, for example, in a bad economy, SMB and ENT might have different behaviors based on those different positions.
In any portfolio theory, having uncorrelated assets yields stability, at the expense of maximum single-year growth. Ideally, still maximizes long-term growth, or at least does on a risk-adjusted basis. In that language, serving both SMB and ENT is a diversified portfolio, which for a maturing company is a strength, because it means it can be more predictable.
I started by mentioned some of the counter-points. There are many more. Therefore I think both strategies are valid and wise. The only thing I believe is unwise, is taking some choices from strategy A and some from strategy B. That’s just a confused and bad strategy!
So pick one or the other, and make consistent decisions based on that choice.
One of the great joys of hosting these sessions has always been witnessing the generosity, the openness, and the deeply earnest introspection that keep the industry going. @asmartbear’s contemplative, astonishingly detailed and perceptive notes (that, as I admitted to him, will surely demand multiple rereads in print :)) have been inspiring additions here. Thank you for pouring so much into drafting these, @asmartbear, and for continuing to document your journey on your seminal, long-admired blog. 
It was also a great honour to have some veteran Relay contributors join us with questions that were as detailed, thoughtful and inward-looking, questions that were instructive, in and of themselves; in the sense that reading them makes one wander further into the subjects they are anchoring and articulating so well. Thank you, @Rand @uibreakfast, @Sofia, @amit, @brendan, @jamesgill, @jasonbosco, @aantix, @kps, @Krish, and @rajaraman for taking the time! 
Thanks so much for the thoughtful reply. Have not heard this bit of wisdom that a team can still be effective and high morale if a single person is struggling (but not if more than one is struggling). That strikes me as a very helpful guide for scaling. Thanks again!
Hi Jason, thanks for doing this. I’m interested to know how you’ve thought about validating product market fit at your different startups. Were you looking for the same/similar signals at each one, or was it more specific to the product / ICP?
Product-Market Fit
It never occurred to me to try to measure it. It was just coming in vogue with WP Engine, but thanks to a process (that in retrospect does help find that fit), that rejected other ideas, but accepted (and refined) the idea for WP Engine, it was successful out of the gate, so I didn’t need to try to measure when fit happened.
Then, in Jan 2012 probably triggered by our thoughtful pricing change (but possibly other things – it’s impossible to know even in retrospect!), our growth went from good to hyper-growth and never looked back. So it was clear that we had PMF, and again I had no need to define it or measure it.
I do have some thoughts about what it means to have it. I know that’s controversial and perhaps in the end it doesn’t matter, but FWIW:
I don’t think efficiency measures are signs of PMF (or signs of not-PMF). So e.g. payback (CAC/MRR) or LTV:CAC or all that – those are fine, but it’s easy to see examples of efficient companies who aren’t growing and thriving, or inefficient companies that are growing like crazy and clearly hit a nerve.
So, basically, growth is almost uncontrollable, yet customers are sticky. That’s the main thing, for me.
I do imagine it might be different in detail with different kinds of products. CPG for example, where you might look at word of mouth especially, but still look at repeat buys (the equivalent of “retention”).
Generally I find that people who are wondering whether they have PMF, don’t have it (because they’d be too busy keeping up with the business to wonder), and most of the time when they declare “they have it” on Twitter, also they don’t have it. I wouldn’t claim that’s an ironclad rule, just a non-scientific observation.
Finally, I do have some thoughts on the ingredients that can get to PMF. It’s not a recipe, and there’s more things that also have to go right, but it’s a lot of details that I think matter a lot.
Thank you for the honest and thorough response, Jason. So happy for you that you’ve found that calling which is also a hobby 
Couldn’t agree more on the probable fragility of new co-founding relations. I’ve also bookmarked (and can’t wait to read) the other essays on decision making. And this is the most concise and illuminating case for specialists at scale:
“But at scale, the details are important, the experience with everything that can go right and wrong is important, the pattern-matching is important, seeing the movie before so not everything is reactive is important.”
I’ve been going through all your responses, one by one, and I’m amazed at how much you’ve peered into the whys behind each and every question. This has been wonderful; thank you for taking the time, @asmartbear!
Thank you for the kind words! Glad it’s been useful.
Love the clarity that EBITDASM can bring and your evolving thinking on markets.
I must say, within the span of these responses, you’ve written a whole book on building and scaling, @asmartbear. Thank you so much for contributing so many insightful observations and lessons. Appreciate you taking the time to draft these with great detail and care.
And thanks also to all the Relay founders who joined in with such candid, and such an engaging discussion. 
I am proud of the documentation of such knowledge in one place for other founders. Thank you!
Thank you for saying so! It was fun to do.
Thanks so much for the answer @asmartbear! On the thoughtful price change at WP Engine, is that the Fermi-style “Evaluating Startup Viability” exercise from your is there a problem post, or are you referring to something else?
Thank you! The price change was just talking to customers more informally and realizing some common patterns. For example, they’d say “Look, I’m happy to pay $99/mo for my big site. But I have these other two really little sites that get no traffic, like one for my mom and one for some little project. Can I just tack them on? You’re really going to make me keep a Dreamhost account for that?” So I decided to allow multiple sites on the larger plans.
I have used this customer interviewing framework multiple times, including in figuring out that WP Engine was a good idea in the first place, and also subsequently inside of WP Engine, so that’s what I would recommend, and what I myself do whenever I want to be more structured and directed.