Jes Kirkwood on November 15th 2021
Geoffrey Keating on April 19th 2020
Calvin French-Owen on April 6th 2020
Lately, a bunch of early-stage founders have emailed me to ask for go-to-market (GTM) advice. They have a real product, it solves a real problem for their handful of customers…
…so why isn’t it selling?
It’s a problem faced by nearly every single technical founder I talk to.
The unfortunate truth is that the first year of sales will tend to make or break the company. Sales provides the initial momentum for a startup to survive. It’s the difference between a Series A, and an Our Incredible Journey Medium post.
The trouble is, I’ve always felt at a bit of a loss when asked for sales advice.
I’ve worked way more on the product and tech side. Until recently, I’d never had a strong framework for understanding how sales actually works.
That changed recently after I attended a two-day sales training. Our CRO hired a consulting firm called Force Management (I know, I know, it sounds like soul-crushing corporate training, but bear with me) to teach all of our GTM teams about sales. I was fortunate enough to sit in.
Bonus: If you’d like to hear a fireside chat between myself and Force Management on the importance of sales in B2B, listen to our conversation below.
Candidly, I was impressed by everything the instructors taught us. They were handing me the exact answers to the questions these founders were asking me for.
My goal in this post is to relay all of those learnings as concrete advice for early-stage founders. By reading it, you should be armed with the framework you need to sell a SaaS product to other businesses (and have a view into the enterprise).
We’ve gotten Segment surprisingly far without having any of this sort of framework. But frankly, I wish we’d known this much earlier on. There’s no reason not to be great at this from day one.
Without further ado; here’s everything I’ve learned when it comes to selling a B2B product.
Note: A version of this post first appeared on my personal blog.
Before getting into tactics, I want to spend a minute on the importance of sales, particularly in the enterprise.
I used to think that “products just sell themselves”. A great product naturally spreads like wildfire.
I’ve since realized that I was dead wrong. A great product may be the backbone of a company, but it’s not sufficient all on its own. Here’s why.
Think about all of the products you buy today–food, gas, coffee.
For the most part, these products are commodities. The cost of the good is dictated by the raw ingredients and the competition; maybe there’s some markup for additional quality.
What that means is that you might encounter a $5 cup of coffee on your morning commute, but a $50 cup of coffee would be unheard of.
Now in the enterprise, these rules go out the window. For most SaaS business, the cost to deliver your product rounds down to zero.
The infrastructure used to run our Salesforce instance probably costs somewhere on the order of $100 per month. Yet, they charge us tens of thousands of dollars per month… how?
In enterprise software, customers pay for software based upon the value that software provides, not the cost to deliver or build that software.
The same product can be sold for $50, or $5,000,000. The price comes down to how much value the buyer is getting from the software. As long as the buyer sees it as a positive return on investment, it’s worth the price.
A great salesperson steers the conversation towards that value. If you’re not anchoring against the value, you are literally leaving money on the table.
The first lesson in sales is: don't think of it as sales.
When I think of salespeople, I typically think of people without my best interests at heart. They’re trying to close the deal. They don’t really know or care about the things I want.
Honestly, this rule applies to 99% of sales interactions I’ve had. Why shouldn’t this stereotype hold if I’m talking to someone trying to sell me something?
Don’t be that 99% of my inbox.
When selling, you have to approach the discussion from a totally different mindset all together. Great sales isn’t about closing the deal. It starts with understanding the customer.
Don’t think of yourself as constantly trying to pitch them on your company. Instead, think of yourself as a consultant or a trusted advisor. You’re trying to help the customer get the outcome they want (and maybe that’s not buying your product!).
Getting there requires two key skills:
actually listening to the business needs and
demonstrating that you’re listening.
To do this, I’ve seen a few different tactics be effective
Do your homework: read 10-Qs, earnings reports, and press briefings. Try out the product or service, and see what customers are saying. Look at reviews on G2Crowd, Capiche, and Yelp. Have an idea of what matters to your customer before that first call. Companies (especially public ones) put out a ton of information on what they want to get done. It’s on you to find it.
Ask “What does success look like?”: anyone considering buying a tool will have an idea of what they want to get out of it. There’s likely some quarterly goal that they want to achieve, or some metric that they want to impact. It’s a great idea to understand what matters most to the customer.
Tie back to a business objective: at the end of the day, businesses traditionally value just a handful of things: increased revenue, decreased cost, reduced risk, or time to outcome. It’s worth understanding what the overall goals for the business are here, because your product should support one of those top-level goals. Saying “We have a better UI” doesn’t really paint the ROI story that you need.
Write it all down: there's one big commonality between our best salespeople: they are constantly taking notes in a notebook. No one will object to you taking notes—and it’s a key way to remember exactly what the customer said. You’ll want to use these notes in follow-up emails and conversations. It’s really easy to do and makes you seem like a pro.
At the end of the day, selling well means that you are helping the customer actually understand their problem, and the path to evaluate a solution. Don’t sell, consult!
Okay, once you’ve started learning about what the customer cares about, you need to get a first meeting with them.
I’ve historically seen two ways work well for this, inbound and outbound.
Getting customers coming to you means that you first have to put something interesting out there.
When it comes to content, my #1 rule for this is teach people something they didn’t already know. It has to be non-obvious, and combine some set of deep research or your own data.
A good rule of thumb is asking yourself “Do I wish I’d read this post six months ago?” It’s easy to become “too familiar” with content that’s actually really interesting.
Priceonomics has the definitive guide on building out interesting content, so if you want to go this route, check them out first: The Content Marketing Handbook.
I’ll warn you right now that inbound is going to be a slower path. But it’s far more likely to succeed for some audiences (developers in particular).
In the early days, we grew Segment by:
Launching Analytics Academy — we realized people were eager to learn more about analytics, and the best way to highlight Segment was to teach them.
If you need a faster path to getting users (or your market requires it), you may have to rely more on cold emails.
As a rule, most people hate getting outbound emails. I certainly do. In fact, we actually used to have a rule at Segment that we didn’t send outbound emails ever).
Most outbound emails I get aren’t personalized. Best case, they feel like spam, worst case, they are downright annoying. I archive almost all of them immediately.
I’ve since come around a bit, mainly because I’ve realized: outbound emails don't have to suck. A few ground rules:
Do your homework: Sound familiar? Make sure that you’ve researched the person you’re emailing. Look at LinkedIn, Twitter, recent talks they’ve given. Make sure you can put yourself in their shoes.
20 emails are better than 1,000: I’ve found time-and-time-again that a handful of emails are better than a random blast. If you need early user feedback, focus on those few users you really want.
Answer: Why me? Why now? If I'm going to get an email from you, you have to make it clear that you’ve done your homework. You have to mention something that’s both relevant to me, and explain why you’re emailing now. For example:
I saw your talk on handling outages, and it got me thinking about entrypoints.
I realized that there should be some sort of tool to make those more apparent. We’ve built a first version that I’d love to show you.
Would you be interested in trying it out?
Get an intro: So many of the founders I talk to don’t lean on their investors hard enough for intros. Yet, it makes me 10x more likely to talk to a new startup if someone else recommends them.
Now, let’s shift gears to what happens when you’re actually talking to the prospect.
The truth of the matter is that 99% of salespeople start with the same exact pitch. It’s pre-canned, it’s not personal, and it’s irrelevant. In other words, it’s far less likely to succeed. It’s the dead opposite of what we want to do.
Remember, let's start the conversation by thinking like a consultant, not a salesperson.
Before ever talking about “what it is you do”, you need to gain a clear understanding of the problems the customer is trying to solve. And you need to have a crystal clear idea of how they are doing things today.
That means asking open-ended, illustrative questions.
As an example, I’ll share a few that are particularly relevant for Segment:
What does success look like? What metrics are you looking to move?
Tell me how you answer a question about your funnel today?
Walk me through the process to gauge the success of a new product launch.
These questions help establish the “before” state; it’s the status quo.
The before state probably has some rough edges. Maybe it’s expensive or a waste of time. Go deep here, you need to figure out where the real pain for the customer comes from. You need to be able to articulate that pain later, so ask questions even if they may seem obvious.
Once you understand the status quo, start probing for what the business should look like in a year.
This is where the “after” state comes into the picture. If the customer could have their dreams fulfilled, what set of things would they want to exist?
Write down that “after” state diligently. Ideally the after state should have a set of “axioms that are now true”, as well as concrete business outcomes and metrics.
Once you and the customer both have a clear picture of the “before” and “after” states, then there’s the natural question of “How do we get there?”
That’s where we get into creating required capabilities. These are the requirements that need to be true to transform from the “before” state to the “after” state.
What these are is not nearly as important as how they are created.
Crafting the required capabilities should be a collaborative affair. If you’re just listing out a set of requirements, you’re doing it wrong. You’ve stopped listening.
Imagine it in the same way that you'd build your product. You don’t just go into a room solo and emerge with a list of strict requirements. You’ll whiteboard them, pressure-test them, and give and get feedback from the customer.
It’s your goal to understand what their list of requirements is. At the end of the day, you want to agree on that list.
To see what this looks like, suppose I’m trying to sell Datadog, an application monitoring tool.
My list of required capabilities might look a little like this:
Engineers must be able to create dashboards to monitor their own services.
Engineers must be able to define alerts which trigger our existing pager system (Pagerduty).
We must be able to record our own custom application-level metrics.
We require SSO support.
Those capabilities are requirements that you and the customer have mutually agreed are important.
Remember, the customer is the expert on their organization, and the needs it has. You are likely the expert on how companies evaluate and buy your software. The two of you need to strategize together to figure out what makes sense.
Finally, it’s the moment you’ve been waiting for! The time to tell the customer about all of the great things you’ve built.
The way not to do this is to put together a laundry list of features you’ve built. Instead, you want to speak to the value you provide—and that means bucketing the problems your product solves into several different buckets.
There are only a handful of types of value propositions when it comes to selling to businesses:
At all costs, you should be able to map some part of your product and its features to these four outcomes.
When I think about the products that we pay for an use at Segment, all of them fall into these different buckets:
AWS increases our speed of iteration
Salesforce increases our revenue
GSuite reduces the fully loaded cost of our email servers
Okta reduces the risk of stolen credentials
Of course, some of these value propositions are correlated (speed often decreases cost), but the key is that they can contribute meaningfully to the business model in some manner.
Finally, there’s The Mantra.
If you remember nothing else from this post, just memorize this section. The mantra is a handy tool to use to wrap up conversations, re-affirm what you just talked about, and discuss next steps.
The mantra should be memorized, so that you can repeat it by heart at a moment’s notice.
If I understand correctly, you want to achieve the following business outcomes…
Which require the capabilities to...
And impact the following metrics...
Here’s how we do it…
And here’s how we outpace our competition…
For more info, you can check out the following proof points…
These six lines help establish mutual understanding. It shows that you’ve actually listened to the customer and their problems, and affirms that your product can really help them.
And we’re done! Well, almost.
No deal is fully complete without a set of qualification criteria.
Plain and simple, this criteria ensures that you’ve covered your bases. It’s a rigorous tool you can use to evaluate a deal and see where you might have blind spots.
Think of criteria in the same way that you’d think of the checklists that NASA or SpaceX use to launch rockets. If any field isn’t checked, you might be missing a key piece of the picture.
The one we use is called MEDDPICC. I’ve detailed it out below.
Metrics are one of the most important parts of a sale. You and the buyer should both be agreed on which metrics the product will impact for the business. That’s how you’ll measure the success of the product (and ideally the ROI).
The economic buyer is the person who actually buys a product—the catch is that they may or may not be the person who wants to use it. In every case, you want to know who can actually make the purchasing decisions.
The decision criteria are more or less the “required capabilities” I talked about earlier on in the post. They determine how the customer will evaluate the product you’re selling.
In every case, a viable option for the customer will be to “do nothing”. They don’t have to buy your product, or any product for that matter.
The best way to prove the case for your product is with your metrics. Doing nothing should be a very expensive option.
Of course, the criteria are only a piece of the puzzle. The decision process governs how customers will actually purchase a piece of software.
This can vary wildly from company to company—so you should take care to understand how your customer actually buys software. Ask questions to confirm:
Who you should talk to in order to make a decision?
What does the timeline look like to get there?
The paper process refers to all the forms, paperwork, and contracts as part of a deal. While it sounds similar to the decision process, DO NOT IGNORE THIS STEP. We’ve had a number of deals fail to close over the years just because we weren’t sure of how the paperwork actually got signed.
Though it’s far down in the acronym, the identified pain is really where you should start with the customer. You should be able to answer in great detail why their life is currently painful, and how they handle the problems you solve today.
Your champion is the customer who is rooting for you and wants to buy your product. In the early stage, it’s likely that your champion and buyer are the same person. But as you grow and expand your deal size, the champion might need to get permission to buy your product.
When this happens, you need to be giving your champion firepower! Help them provide collateral to the rest of their organization to teach them why your product is the best!
Lastly, you should know your competition. It could be internal efforts, it could be competitors, or it could be doing nothing at all. In each case, make sure you know why the customer is considering your competition.
At the end of the day, selling well means understanding your customer.
In some sense, sales is just another form of finding product market fit. Instead of helping a customer use a product, you are helping them make a decision.
If you take nothing else from this post, remember that your customer is the expert on the problems they want solved. They have an extremely detailed view of what matters to their business, likely crafted over years. It’s your job to help them understand how those problems map to the different products on the market, and how to make the decision to buy your product in particular.
As a final parting thought, I think most of the lessons here aren’t just applicable for startup founders. They’re useful for anyone who wants to sell an idea within their company, or establish a culture of elite sales from day one.
Seek to understand first. The rest will tend to follow.
: A notable exception to this are Infrastructure-as-a-Service (IAAS) providers.
Olivia Buono, Sasha Blumenfeld on March 31st 2020
Over the last few years and increasingly today, changes to our global economy and rising customer expectations have forced businesses to adapt quickly and often. The shift we’re seeing in the market today is forcing change at a pace and scope that we haven’t seen before.
If you’re already a digital business, you need to optimize for financial performance today. If you’re still on your transformation journey, you need to speed up your investments into the digital business models, products, and user experiences that will carry your business into tomorrow. Balancing these priorities can be a difficult challenge, especially when the stakes are high and the timeline is tight.
We’re seeing our customers rise to the challenge by building a deep understanding of their end-users and quickly mobilizing that knowledge across every team and technology. Here’s how your business can use the Segment customer data platform to accelerate marketing impact, make better product decisions, and build a resilient tech stack.
Effective marketing doesn’t necessarily require more people or budget, but it does require a better understanding of your customers. Segment helps you unify each interaction into trusted user profiles. We then help you turn those profiles into real-time audiences, like “High-Value Buyers,” which you can feed into a variety of tools to ensure all of your marketing channels are working in tandem. With reliable data at your fingertips, your team can launch marketing campaigns faster, rapidly iterate, and personalize with confidence.
Personalization can have a significant business impact. According to Forrester’s Total Economic Impact Report, Segment helps companies test marketing campaigns five times faster and deliver 33% better conversion rates. To navigate the current climate, marketers should be looking to:
Reduce wasted ad spend by immediately removing recent purchasers from campaigns to focus spend on those who haven’t converted.
Make the most of your high value users by using them to create look-alike audiences that power your new user acquisition.
Optimize budget allocation by connecting all online and offline data to run more complete marketing attribution and make informed budgeting decisions.
Here are a few examples of how Segment customers are accelerating marketing impact:
Consulting.com improved ROAS by 10% using Segment's Identity Graph and event-based audiences to build seed audiences for Facebook lookalike campaigns.
Digital Ocean drove a 33% improvement in cost per conversion by rapidly optimizing digital ad campaigns using Segment to create granular audience targeting.
Product teams make hundreds of decisions each day. In times of uncertainty, you need their decisions to be as fast and well-informed as possible. Whether it’s the decision to build a new product or streamline onboarding, they should have an accurate picture of how people use their products and the impact their products make on the business.
The most agile product teams have access to high-quality data and make data-driven decisions. A complete customer view doesn’t just allow marketers to personalize different channels, it also allows product teams to quickly run A/B tests and drive product adoption. When all of their tools are connected to Segment, product teams are also able to quickly analyze data and generate insights without redundant engineering efforts. Right now, product teams should be looking to:
Understand which features drive revenue to create opinionated onboarding and growth experiments that lead users to take action.
Enforce a data dictionary so that entire product team has consistent analytics across every product or customer touchpoint.
Build propensity models with trustworthy data that doesn’t require days of cleaning by your data science team.
Here are a few examples of how Segment customers are making better product decisions:
IBM increased product adoption by 30% and billable usage by 17% in three months using Segment to standardize customer data across divisions and provide visibility to drive efficient nurture programs.
Imperfect Foods increased user retention by 21% with a fast experimentation cycle—22 experiments in 6 months.
Norrøna saw an immediate 50% lift in conversion by automating product recommendations based on seamless data collection in Segment.
The technology stack you have today won’t be the same one you use to tackle the digital problems and opportunities of tomorrow. And as new tools spring up every day, it can become unclear whether to switch now or how to make the most of what you already have.
When considering a new tool, you’ll naturally want to test it with your own data. Historically, that meant you needed to convince your engineering team to build a data pipeline and create yet another data silo. The alternative—not testing—could lead to a lot of wasted engineering hours spent on a tool that doesn’t work as advertised. This resource-heavy process of bringing on a new tool has caused many businesses to simply accept the status quo.
Segment helps you de-risk this problem by making your customer data portable. Segment makes customer data fully accessible to the tools you already use to help you maximize each investment. When you decide to test new tools, Segment helps you test using your complete data set, rather than a sliver, and limits the engineering work required to hours, not months. Many engineering teams are turning to Segment because they can save millions of dollars by being able to integrate and experiment more quickly. Engineers can also use Segment to:
Streamline customer data collection that’s trusted and actionable across every team in your organization.
Connect your data to hundreds of tools with out-of-the-box integrations and the ability to build your own logic for custom workflows.
Give your team the ability to adapt your tool stack in a way that enables you to keep pace with customer expectations.
Here are a few examples of how Segment customers are building a resilient tech stack:
Clearscore launched in a new market at 1/3 the engineering cost of building an in-house solution that would allow them to comply with regulation using their existing tech stack.
Heycar quadrupled digital conversions and tripled user retention by using Segment to implement a new analytics tool that gave their product team instant data insights.
Halp improved activated digital sign-ups by 4x in less than a week by connecting best-in-class tools they were already using to launch a new digital onboarding experience.
The move to digital business is accelerating. The seismic shifts over the last few weeks are just the beginning. If you’re already a digital business, you need to prepare as usage continues to evolve. If you’re making measured moves toward digital, your transformation timeline needs to speed up to meet our new realities. It’s critical that you quickly tackle the new challenges ahead, so you can build new digital experiences for customers while the opportunity is still there.
As you evaluate your strategy across marketing, product, analytics, and engineering, consider whether you’re prepared to empower each team with the quality data they need to drive business impact and create tailored digital experiences. Also consider if you can do it fast enough and at the scale your business needs.
If you want to discuss how customer data can accelerate your strategy and power your digital business—with or without Segment—reserve some time with a Segment Growth Expert today.
Doug Roberge on March 25th 2020
Geoffrey Keating on March 23rd 2020
When you’re the parent company of multiple brands around the world (and investing in new acquisitions all the time), it can be a balancing act to know how to build a tech stack and manage it across your global brands.
Should you enforce a particular set of tools globally? Or should you let each of your businesses build or buy their own solutions as their individual geographies and needs dictate?
As Cimpress has learned, the answer is a little of both. The publicly traded mass-customization conglomerate owns brands all over the globe such as Vistaprint (in The Netherlands), Pixartprinting (in Italy), and BuildASign (in Texas) and operates manufacturing plants on every major continent. With more than 10,000 employees and a $3.11 billion market cap, the stakes are high.
At such a massive scale, it can be helpful to develop a set of design principles that can guide your decision-making. For Cimpress, there are two golden rules: 1) choose tech solutions made by challengers and visionaries with an extensible, API-first mindset, and 2) avoid legacy companies that might be lagging behind as they try to evolve their monolithic platforms.
We sat down with Abhishek Dwivedi, Cimpress India’s Senior Director of Technology, to learn more about how he walks the technological tightrope between centralizing and decentralizing the parent company’s software offering.
As a product development veteran of companies such as AOL, Oracle, and Anthelio Healthcare Solutions, Abhishek has had nearly two decades of experience sifting through the 21st century’s shifting software landscape. He became the Head of Technology for Vistaprint India in 2012, just two years before it was acquired by Cimpress.
Today, he’s responsible for tracking down best-of-breed solutions and figuring out how to leverage them for cross-platform integration, machine learning, and cloud infrastructure.
We’re excited to share how companies like Vistaprint empower teams and deliver real-time customized experiences for customers using Segment and Amazon Personalize.
This is the second in a series of real-life stories from leaders who have seen their stacks evolve in extraordinary ways. (Check out our interviews with Frame.io and Datadog about how they evaluate key technology choices.)
Our chat with Abhishek ran the gamut:
The difficulty of using a cookie-cutter approach for brands with diverse business models
Why Cimpress looks for “thought partners”: companies that are willing to listen and adopt design inputs instead of simply being vendors
How his team creates a mesh of services to address data infrastructure, visualization and distributed microservices
How following the concept of a minimum viable product helps them understand their customers’ journey at a high level and evaluate the technology they need to serve them best
Dive into the interview below.
Geoffrey: What sort of technologies were in place when you first started at Cimpress? What was working? What was not?
Abhishek: When I joined Cimpress, it was just one entity – Vistaprint. I joined in 2012 as head of technology because they were rolling out the Vistaprint brand in India.
Technology at that point took a cookie-cutter approach: you are in X country, and you decide that you want to be in Y country, so you would just basically copy the tech stack of X country and apply it to Y.
We had no way to help you adapt to the customer journey in that locale. That was a big, big challenge for us, because the stack was inflexible and monolithic in nature. You could neither extend it nor change it to impact the customer journey.
Geoffrey: So technology was centralized? How much flexibility did different locales have?
Abhishek: The company started in 1994, 25 years ago. When the company started, it was great for US markets, where the highest level of flexibility was available. You could be in one market and have a monolithic stack.
But when you start experimenting in Europe or Pan-Asian markets, things get harder. You had to move from a world where everything was centralized to a multi-brand, multi-country strategy.
Different regions want to take control of their own technology, but since the stack was monolithic, the level of control they had was actually very, very limited.
Geoffrey: What were the triggers that caused your stack to change from this cookie-cutter approach to where you are today?
Abhishek: We started to evolve as an organization for two big reasons. One: we wanted to go global, which meant we needed to be present in Asia. Being in the US and Europe doesn't make you global. That isn’t just limited to rolling out technology specific to each region. It also expands into marketing activities, plant operations, logistics, and so on and so forth.
The second trigger was that we started to make a slew of acquisitions in early 2013. We started to realize that a multi-brand, multi-country strategy would require flexibility on a per-region basis, but also a certain level of commonality in logistics, fulfillment, network, routing, and so forth.
Let me explain.
Within each region, there is some uniqueness. Is it B2B, B2C, or both? Is it a reseller? Are there closed borders, wide borders? Each region will have a unique way to bring a product to the market.
However, there are also commonalities that each region needs from its technology. There is a common set of things a business like Cimpress can offer to its subsidiaries. This cuts down their total cost of ownership and means they don’t have to execute a technology strategy completely independently.
Geoffrey: I'm guessing that when you acquired a company, you acquired their technology stacks as well.
Abhishek: Yes, we acquired the whole company. Getting all of them under one technology umbrella was a hard task.
This is actually how Cimpress came into being. As a holding company, we said: “Okay, we will invest in legal, finance, supply chain, and technology. This tech will basically power the platform on top of which these different businesses sit.”
We have created a level playing field for these businesses. Businesses can leverage the Cimpress technology platform, but at the same time, we preserve their brand identity, fuel their growth, and help them expand in a cost-effective manner.
You could describe it as decentralization with the support of a centralized platform.
Think of it as a pyramid.
What is common between the businesses for leverage? And what is unique for the businesses to deploy themselves? But some of the businesses have their own customer experience and their own technology.
Geoffrey: On a tactical basis, how do you keep data in-sync across all these different teams and tools and technologies?
Abhishek: Primarily through two things. Firstly, through event-driven infrastructure and microservices. Secondly, though common data infrastructure and data warehouses that we provide to our businesses. We also provide a lot of central tooling. like visualization architecture. We give you things you might not want to invest in, but you’re free to leverage them for your own needs.
Geoffrey: How does Segment fit into your stack specifically?
Abhishek: There are two locales in Europe that are using Segment. It is very clear that they understand Segment's potential, and are looking to harness it in new ways.
They have just introduced a Google Analytics integration with clickstream data coming into Segment. Soon, we’ll be able to tap into much more, like server-side data, events, etc.
Now that they’ve realized the potential of Segment, we want to move strategically into the area of identity resolution. This is the product within Segment where there is huge leverage for a business like ours that has analytics, marketers, engineering teams, and many different channels. These different units can then come together around Segment.
There’s big potential here in areas such as customer care, where we’re trying to realize identity and clickstream behavior while interacting with the customer.
Geoffrey: Obviously Cimpress is a fast-growing company. With that in mind, how do you ensure the tools you choose today can grow with you over the course of 12 or 18 months?
Abhishek: The one golden rule is that we never choose anybody in the top quadrant of Gartner or Forrester. We tend to choose people who are challengers and visionaries, because they are new-age, and they are not trying to refactor their platform from being monolithic to API-first.
The second rule comes down to our technology design principles. The technology we adopt should be extensible, it should be API first, and there should be an engineering-first mindset. If you take Segment, if you take Algolia, these are all engineering-first, API-first products. These company’s investments are in tech, and their core values are geared toward doing one thing as opposed to doing all the things (and not being good at anything).
Doug Roberge on March 2nd 2020
Jon Sadow, co-founder and Chief Product Officer at Scoop, recently hosted an AMA with the Growth Masters community. The questions he received were incredibly varied, from more theoretical product strategy questions to in-the-weeds questions about Scoop’s analytics implementation. Read through the AMA transcript below to tap into Jon’s extensive knowledge about product strategy, growth, and carrier development. Plus, you’ll learn about his greatest piece of advice and lessons learned as a co-founder.
If you want more details on what’s discussed below, check out Jon’s Growth Masters lesson. Enjoy!
I have to thank my daily carpool commute with my older brother Rob (and fellow Scoop co-founder) to our high school in Atlanta for the idea for Scoop.
By the time I was 14, Rob and I were commuting 250 and 300 miles each week to get to school.
Needless to say, I realized the pain and stress of a long commute early on, from planning my entire day around the drive to school to feeling drained before we even walked into class. Both my brother and I became well-acquainted with the toll such long commutes took on our physical and emotional health and sense of well-being.
There was one thing, though, that made it better: sharing that time with Rob. I had someone to talk to, debate sports, blast music, and talk about our days. The impact was real: it made all those miles seem shorter, and we’d get to school feeling just a bit happier and more energized.
That was just the start. I encourage you to read our story in Forbes to learn about our journey from ideation to launch!
The Product team is involved in the overall growth strategy for the company, and it's important to call out that that's heavily influenced by the fact that I am one of two co-founders :)
So, that does, of course, make it much easier to ensure that Product is deeply involved (if not driving) the core growth priorities of the organization.
But what really has unlocked that involvement by Product – and nearly every other team – is building an egalitarian culture. We've gone out of our way from day 1 to make sure we have cross-functional equality and appreciation. Our engineering team appreciates and cares about what goes into sales. Our operations team appreciates that we have to make hard prioritization trade-offs. We don't prop up one function as superior to the others.
That level of appreciation and respect makes it natural for nearly all functions to be involved in our growth strategy and to collaborate naturally.
We're using Personas! And we're super happy with it, especially paired with Sisense's Data Engine.
Between the two, we've been able to enable our Analytics teams to create transformed tables and then write queries against those tables to define segments in Personas. From there, we can trigger behaviors into our marketing flows and other in-app interactions. So, that's super powerful.
We approach it in a few ways:
Do a lot of it. Talk to as many customers as possible. That doesn't mean you should do what they say, but there is no downside in hearing them.
Invest in user research from the very beginning. This was critical for us and is probably the most important suggestion I can give to any product leader at an early stage company. User research is fundamental, and the most important way to optimize your approach is to have great people on your team whose priority is that research.
Everything stems from these two ideas. Yes, there are meta points on disciplines, methodologies, etc. but if you do #1 and #2 correctly, those happen naturally.
The best insights we get out of customer research come from understanding context and mindset. It's easy to say, "What do you want to do?" or "How did you like it?" It's much more insightful to understand what mindset they're bringing to the equation, what their normal behavior is, how they view change, who they are as people, etc.
Users and customers are people, and so the human context is where the magic lies.
I’m a believer that the most effective way to approach prioritization is to treat it like a religion, not just a process.
When I first became a PM at Google, I was lucky to be taught and mentored by a guy named Paul McDonald, who led Gmail for a while, and has since left to start his own AI-vending startup Stockwell.
He drilled into me that prioritization was everything for a PM and to be great at it, you had get comfortable scrutinizing yourself and your decisions.
That’s a hard thing for people to do naturally. For him, it wasn’t the scoring, or ranking, or revenue projections that made the difference, but developing an obsession with ensuring the energy and focus was being put into THE most important thing.
At Scoop, we’ve been most successful when we are maniacal about focusing on the one thing that matters most. Almost always, that’s whatever specific value we are trying to deliver to the user and why. Our best prioritization decisions have come when we challenge ourselves from all angles about how to realize that value. When we do that, we avoid falling into the trap of justifying a “nice to have” or, even worse, “an easy fix.”
When we’ve struggled, it’s because we over-committed to a feature we added to the roadmap a long time prior, ignoring that the world around us had changed.
As an organization, we’ve also really benefited from consistently inviting new instincts, user research, data, and healthy doses of pragmatism to challenge our priorities. And ultimately, we strive to stay extremely honest with ourselves about where the current product is falling short. That’s often the best indicator of where we should go next, and that humility is the best guiding light.
If I could go back in time, I would have loved for our team to invest in our Customer Dashboard and insights platform earlier on. It’s been one of our biggest product team priorities for a few quarters, so we’re certainly making a significant investment now. But, as we continue to see how meaningful it is to our customers and Scoop’s growth, it’s hard not to wish we had this since day one!
Now, like most product people, I can (and will!) certainly make a good case for why we made the right prioritization choices at the time. After all, what’s unique about Scoop is our B2B2C model. The number one core value our customers get from partnering with Scoop is driven by the individual impact we have on their employees – the commuters.
So, it was always easy for us to stay focused on the commuter side and put our resources and energy behind the Scoop mobile app. When we started Scoop 4.5 years ago, we were creating a new category, and our customers didn’t even know what type of product capabilities they wanted. As their needs began to take shape, we understood we’d have to invest in more product capabilities specifically for them - our stakeholders and buyers.
But what I think we – or I – missed, was that it wasn’t just that we would have to build a customer-driven product. It’s that we would want to. I wish we had realized sooner that we could do a lot more than meet their needs. Instead, we could look to accelerate our ability to deliver even more value from Scoop via a customer-driven product.
Today, we’re antsy with tons of ideas of how to really empower the customer with full control and visibility into the impact Scoop is having and aggressively working to bring that to life! It’s exciting to see these ideas come to fruition. More than that, it’s a fulfilling feeling to know we are building a product rooted in Scoop’s mission to enrich millions of lives by helping our customers choose to make the commute a meaningful part of the day for their employees.
What's unique about Scoop is we are a SaaS business in terms of our customer orientation/business model/go-to-market. But, the end-user behavior we unlock behaves a lot like a marketplace. So, we have the fun challenge of measuring and tracking the performance and growth in both places!
In each category, our success metrics look a lot like what you'd see at other SaaS and Marketplace companies. On the SaaS side, it's a common mixture of top-line, efficiency, and sales productivity metrics. So, revenue, gross margin, CAC, annual revenue retention, etc.
On the marketplace side, it's fulfillment rates, cancellation rates, user satisfaction, other liquidity metrics, etc. What you'll notice is our metrics aren't particularly unique - and that's by design. There are a lot of downsides when trying to come up with "special" metrics for your business. Sure, there are times where your business needs a different way to be evaluated. But the market is still going to evaluate against the comparable data in your industry/sector/competitive set.
The more you have to "teach" an investor on how to evaluate your business, the more risk. So, in general, we don't try to over-complicate the metric types. Instead, we focus on which of the many types of SaaS or Marketplace metrics we are prioritizing from a growth/operations perspective.
As far as how these have grown since Scoop started, the biggest change is the emergence of our SaaS side. That wasn't always the core operating model, and as we've matured in our B2B go-to-market, our success measures have evolved in parallel.
Focus on delighting a core group of users before you scale. We often get excited about MORE users, but as we do that, their desires/interests become more diversified. Retention is just a reflection of how well you deliver what a user is looking for. The more types of users looking for more types of value, the more likely it is to under-deliver for some. So, focus on the core segment, make sure you are listening and reacting to what can deliver for them, and grow out from there.
Track it! Most products start tracking retention way too late, both in terms of the tools/attention, but also by looking at retention in months or quarters, and not weeks. Most retention curves break way earlier than we think.
Obsess over qualitative feedback as much (if not more) than quantitative. Retention metrics also push us toward volume feedback, data slices, etc. In the early days, you need to be getting (and filtering) as much feedback as possible. Hire a user researcher early on (or contract with one). Understand where expectations are misaligned (since that catalyzes churn).
As far as warning signs, the best answer I can give is cohort data. I know that's not novel, but the signs of retention issues are retention issues - you just have to track and visualize them well.
The most applicable thing that comes to mind is an early feature we built called the “Community Map.” When Scoop first launched, the most common questions we had were around “Is anyone else on this thing?” That was logical, since we were just getting started and one of the hardest challenges in carpooling is the “first day” problem.
We decided to build a basic map to visualize the community surrounding someone’s home. The goal was really just to say, “Hey, look on the map, there are other people!” with the hope people would explore this and answer the question themselves.
They did! And people were visiting the Community Map. In fact, we found that nearly everyone was looking at it in their first experience, which was great. The unexpected consequence, though, was that it was creating a whole host of new questions.
The dots got them excited to learn more about who those people were. Did they work at the same place? Were they new to Scoop? How many trips had they taken?
Based on this, we doubled down on the Community section and launched a big feature called the “People View.” This was a visualization of different “lists” of people in your area, including Co-Workers, Neighbors, new folks, and Favorites. This became so core to our product experience that we rebuilt our onboarding to frame the experience as “joining the community,” eventually landing them in the Community Map post-registration. As you might imagine, we’ve found that folks who interact with this section are far more likely to schedule a Carpool after registering.
All because we wanted to try to answer an early question that flooded support!
There are certainly UX designers and experts who can give a much better answer here, so I want to start with that caveat.
What I can share is that the most valuable thing we've done at Scoop is to approach the User Experience holistically -- starting well before the first screen of the app. The user journey is a long, complex one, and many companies/products make the mistake of only thinking about the in-app experience.
We've often said at Scoop that "user experience starts with the Scoop postcard someone receives in their building lobby and extends to interactions with our support team."
The point is that we tend to think that "experience" has to be physical. But what I learn about Scoop when I first become aware of what I see in the app store, to what I see in the app all influences my understanding of how Scoop works and how likely I am to be satisfied.
So, my suggestion here is to figure out what you believe a user needs to learn to be successful and then really thoughtfully map out WHEN and HOW they need to learn that throughout the user experience. Then you can create a "tour" that starts before they even open the app, and is reinforced through the in-app and out-of-app experiences they'll have.
I think it depends on where the investor is and what their investment thesis is. Smart investors are looking for market opportunities that they can appreciate. If the market opportunity is large and familiar, they'll be excited.
So you have to identify someone who understands the market (industry, country, culture, etc.), show that it's large, and prove (or give confidence) that you can conquer it. Not every investor will understand the market or care about it, and that's okay.
Just remember the most important part here is "proving you can conquer it." If you can show that in a large market, you will ALWAYS find an investor who will invest.
The short answer is: figure out which has to come first and commit. It's nearly impossible to try to grow a marketplace in parallel from the beginning. You need to identify the constrained side of your market and do everything possible to invest against the experience quality and growth of that side.
Uber did this better than anyone. They were obsessed with Driver supply in the early days and did whatever it took to make sure that they had enough Drivers to ensure the Rider experience was excellent. Once that experience was excellent, the rider demand grew organically (as we all know).
So, you have to decide which is the naturally constrained part of the market.
First, I appreciate you putting your energy into thinking about how to support and serve folks in uniform. Not enough technologists think about how to serve these segments of our communities, and kudos to you for doing it!
I think what we're asking here is, "What does an angel investor need to see to get excited enough to invest?" Market demand is just one element of that, and showing market demand can come in many, many forms.
Investors look to invest for a lot of reasons, and so it's important to remember that there's no secret answer here.
The best advice I've received on this is to show "lines, not dots" to investors. This is especially true early on.
So what does that mean? A "dot" is a data point – some number of actions, users, behaviors, etc. But a dot has no context. We don't know if it's a lot or a little. And every investor, market, product, etc. will judge that differently.
A line connects to dots, literally. And so if I have a line, I can understand at least where we were and now where we are. That tells me a lot of things. It helps me understand trajectory. It helps me understand relative traction (vs. time, usually). It helps me orient toward the relative values that matter in this market.
The best way to build buy-in from an investor is to communicate lines and bring the investor along as the line grows. Investors want to know that you can execute against what you promise/envision. So if you can say "Here's where we were...here's where we are...here's where we're going" and then SHOW them that you can get where you're going, they will believe in you. That is a HUGE part of the equation.
In your case, I would push you to think not about "How many signups" but instead, how those signups (a) evolve over time, and (b) what underlying value that can be connected to (engagement, behaviors, etc.).
Always communicate a clear long-term product vision to your team - and the entire company (or at least the organizations that surround you). I learned this lesson myself just last year.
As the company grew up, I had started to take for granted the natural alignment between the company vision/mission and the product vision. Naturally, these are nearly indistinguishable in the early days of a startup. In the early stages, you’re only focusing on a narrow product scope, looking to understand if you can reach some baseline of Product-Market Fit.
Once you do, your company shifts into its “adult” phase, which is about operations. And operating and scaling effectively means the number of areas of strategic investment grows too. Put another way, you have more people doing more things, and the core product vision you had early on (that you probably didn’t have to communicate as often) becomes outdated and unfamiliar to newer team members.
Also, I should note that the same thing applies to product teams at bigger companies, just in a slightly different form. Your product org, or pillar, or focus area has its own lifecycle. Teams grow, new faces come on, and the original mandate or organizational impetus for the product you’re working on changes. But it’s still your job to lead your team and collaborating teams in the right direction.
As a product leader, it's easy to ignore the gap between what you have in your head and what has been communicated (and digested) by the team. I had a clear vision in my mind of where I saw Scoop’s products going in the next five years. And it was even influencing near-term prioritization. But I took for granted that others had the same clear picture.
While some folks had lots of the pieces, I was overlooking the many different degrees of understanding, familiarity, and experience we had in a now much larger organization.
Fortunately, with some good pushes from our engineering leadership last summer, I focused in for nearly 6 weeks, and worked to capture that updated vision, socialize it, get feedback, and bring it to the company alongside our company Vision and Mission. The impact was immediate – and really powerful. It’s been ~1.5 quarters since, and it’s become fundamental – in large part because we’ve really communicated and referred back to it over, and over, and over. Now it's the foundation for our quarterly planning, roadmap development, and even our operational priorities across the organization.
Ha! I would love to help everyone avoid some of the mistakes we've made ;)
The biggest product-related mistake(s) I've made have to do with "commitment bias" or the sunk cost fallacy.
It's natural for us to envision features/capabilities we really think should be built next or down the road. But a lot of the time, our world changes by the time we get there. We make the mistake of holding onto what we had prioritized before. We've had this happen a few times, and in retrospect, we should have stepped back and reprioritized. We shouldn’t allowed ourselves to be emotionally invested in something just because we thought it was the right answer a while back.
The most important resource I'd recommend is to find a mentor. There are a lot of obvious reasons why this is valuable, but specifically, the upside is having someone who sets a baseline for you as a Product Manager.
What do I mean by that? There are MANY different ways to be a great PM and many different underlying skill sets that lend themselves to being successful. There's no one way, and that's why there's tons and tons of content that will tell you hundreds of different "must-have" approaches and skills.
The reason a mentor is so valuable is it's a forcing function to start building your Product Management philosophy off of the mentor as an archetype. It allows you to have a starting point for what you think "really good" is, and then adapt/evolve/build on top of that. It doesn't mean you should aim to do everything they do, but you can let them create the foundation or baseline, and then grow from there.
If you don't have that mentor or are still searching, I'd encourage you to try to build the same baseline regardless. You can do this a few ways:
Pick a product person who you want to model after, even if you don't know them! Find someone who has written/shared a lot, identify their philosophy as a baseline, and work from there.
Irrespective of your limited experience, just set your own baseline based on the best PMs you've seen and your gut. For one, you'll want to get good at sharpening your gut/instincts as a PM in general. But beyond that, you can still have an initial POV on what great PMs do, and then build off of that.
The reason I give this strong push around baselines is because the risk of so much content is that you can be unfocused on what you're trying to optimize for and how you're looking to grow. The critical thing early on is to sharpen one core competency after another, and so that baseline/archetype will force that discipline and prioritization.
If you want exclusive access to AMAs like this in the future, sign up to the Growth Masters community today.
Doug Roberge on February 12th 2020
Gustaf Alströmer, Partner at Y Combinator, recently hosted an AMA with the Growth Masters community. Having started the growth team and Airbnb, and advised hundreds of startups on their growth strategies, his insights are incredibly helpful. In the AMA, Gustaf shared his thoughts on marketplaces, acquisition best practices, team structure, and more.
If you want more details on some of what's discussed below, check out Gustaf's Growth Masters lesson. Enjoy!
How should product teams be involved with growth?
Many of the best former growth leaders are now running product teams, like Casey Winters, who now runs product at Eventbrite. I think this shows that many of the things that growth teams introduced are now widely adopted by product teams.
Anu Hariharan, Partner at Y Combinator, also wrote a great guide about the relationship between growth and product.
What are the main indicators you watch out for to determine whether a team has a good product workflow and understanding?
There's a lot that goes into building a well-functioning product team that can consistently execute against a plan. To me, a product manager has a couple of primary responsibilities:
1. Understand, measure and drive the business goals
2. Inspire, motivate, and manage the team's execution.
There are, of course, more things that are critical for them to do, but these are the two most important things, in my opinion.
To start with the first point, any company needs to figure out a meaningful metric that represents the value the product is giving users. Ideally, the metric is trackable daily/weekly/monthly so that you can use it to evaluate your own success.
Second to that is goal setting. What are some team goals you can set for that metric, and is the team aware of those goals? Additionally, I'd be wary of single-metric product teams. Nothing is simple enough to measure that you can capture it all in one metric. You'll need both a growth and a quality metric, for example.
Finally, as a PM, you have to inspire and motivate your team. That means giving them the opportunity to do what they do best, praise great work, and provide feedback when improvement is required. A great PM can build a team that drives success. She gives credit to the team when they succeed and absorb the feedback when the team fails. Those are characteristics that give you the respect you need from your team.
What growth metrics do you encourage folks to keep a close eye on while they're in YC? What metrics would you look at when considering investing in a company, and what would the numbers need to be?
For most companies, revenue is a pretty good metric to focus on. Sometimes there are other metrics like GTV/GMV and API calls that work better, but for most companies, its revenue.
You can see a great talk by Anu Hariharan about metrics below:
It's also important to note that when we interview/invest, we don't primarily look at metrics as a proxy for a successful product. We look at metrics as evidence for founders making progress, making sure they launch and get their product in the hands of users. We don't expect metrics to be great in the early days
What are the biggest mistakes that companies can make surrounding growth? What should every PM at a startup keep an eye out for?
I find that early-stage startups often make the mistake of thinking they have product-market fit and then scale up things like employees, sales, marketing, etc. before they are ready.
I think one reason this happens is that after you've raised a funding round, it's easy to mistake funding for product-market fit. Nothing about your product changes just because you get $2M in the bank, but the actions of a startup often do change. PMs should look out for this and always measure the retention of their customers. Make sure they are getting real, repeatable value for your product.
The best thing a great PM can do is just to focus on the customers and their needs. If you build a great product, many of the other decisions become easier over time.
What are the most popular acquisition strategies employed today?
For this question, I'll pull from my experience at Airbnb.
On the guest-side:
Word-of-mouth from existing guests/hosts
Online marketing. Mostly SEM I believe but def other channels as well.
Referrals. The Airbnb referral scheme still drives somewhere between 5-15% of guest growth (I don't have the up-to-date data). Referrals remain an important growth channel for products where the use case is new and unique, and you often need an existing user to convince you to use it.
4. SEO. We have/had an all-star SEO team, but beating Homeaway, Tripadvisor, etc. was not an easy fight. I believe Airbnb still ranks #3 on average for relevant keywords. We should be #1.
What lead gen tools do you recommend when you're just starting out?
I talk about this in detail in the talk below.
You don't need expensive lead gen tools in the beginning. There are affordable tools available out there, and you can get very far with just spreadsheets and email. Here are a few ideas.
What was the most successful single growth tactic that you used at Airbnb?
I think this question is an example of some assumed short-term thinking on our part.
The best growth tactic we did was to set up the growth team, to give them the tools to move independently, to not centralize decision-making, and let each team execute on the areas of the product they were working on.
That led to things like:
a fantastic referral product
the rollout of instant-book
excellent authentication-methods and managing of identity/trust etc
I think you have to have a holistic view of this. What made us so successful was the system that independently creates the ideas/wins, not the individual ideas themselves.
How did the Airbnb growth team change (in terms of roles and structure) as Airbnb grew?
I worked on the "guest" growth team for nearly five years, and if I look back, we certainly learned things over the years that were non-obvious to us back in 2012.
First, on the guest side, Airbnb has a pretty clear funnel with four main ways customers are discovering the product. As I mentioned earlier, those were: word-of-mouth, online marketing, referrals, and SEO.
Each of these functions was important enough to require its own team, and we built an engineering-led team for each of them. We also had three specific teams focusing on signup, login and authentication, translation and onboarding, and engagement and re-engagement.
We learned that onboarding matters more for people that have high intent to book and less for people who are just checking out Airbnb for the first time. This might sound unintuitive, but we simply found that it takes a very long time to learn if you built something great for people that show very little intent to book on your product.
Each of these teams typically started with a single function, maybe an SEO manager and an engineer. In the cases where there were no engineers available, people had to learn to code or pull their own data in order to their job. Over time we staffed every team with engineers, designers, PMs, and data scientists. Each team had specific metrics and goals they were meant to drive. But they had a large amount of freedom to execute and experiment within those bounds.
How does a data team get buy-in from PMs and developers to build a culture of data?
I think this is an equal responsibility between PMs and Data Scientist, not just the data teams. Data is an excellent representation of everything that goes on with your product. It's not the only input – it's hard to feel empathetic about users by just looking at data, but it remains a critical way to run your business.
Some basic things to help build a culture of data in the early days are to:
Make sure you are tracking the right things, using Mixpanel, Amplitude, and Segment.
Set up funnels for the crucial metrics/business metrics.
Share those metrics over emails, in presentation, and on a monitor in your office regularly.
For a two-sided marketplace, how do you recommend balancing supply and demand? How much supply do you need to build up before focusing on demand?
This is a common question I get. In fact, I get the question more often than I see the problem. Most successful marketplaces start with great, almost curated supply. Then you have to work to get the demand. That can come from any number of channels like word-of-mouth, paid marketing, referrals, etc. My friend and co-worker from Airbnb, Lenny Rachitsky, has written some of the best work on how to build supply in the early stages of a marketplace.
In the early days of Airbnb, Brian Chesky spent an entire year staying at different Airbnbs to understand what really matters to customers. What he found is that hospitality is a critical part of the experience and so the company started to care more deeply about the offline experience. Airbnb wasn't just a website with listings. They cared about every step of the Airbnb experience. It wasn't just about supply. It was about a high-quality, reliable supply.
Do you have any strategies or tactics to improve LTV and repeat purchases for a product/service that's notoriously one-off and need-based?
I think this question could mean one of two things:
1. You either have a bad product, and people choose not to use it repeatedly or
2. You have a great product, but for whatever reason, people don't use it repeatedly.
We actually had the second problem at Airbnb, which is quite unique. 90-95% of Airbnb bookers said they had a great experience, but only about half of them would use Airbnb again within 12 months.
We had our best user researchers try to understand why, and their analysis was that people forgot about Airbnb. They didn't know that Airbnb also had listings in cities, vacation rentals, and so forth, so they simply went back to Google when making travel plans.
There were a couple of different ways to deal with this problem. We could build an inspirational re-engagement strategy to get people to be reminded of Airbnb every month. This sort of worked. Or we could make them install the app on their phone and which would make us the default travel search engine.
What made us hopeful was the gradual shift in wallet share towards Airbnb over the first 2-3 years of a customer's lifetime. What's important here is the time-horizon. One booking a year is a very low frequency of use for a product but completely normal in travel.
How do you balance getting a new product in the hands of a good deal of users without leaving a bad taste in their mouth if it is under-baked?
I think founders often make a mistake, believing that "If it's not near perfect, I will blow this launch, and people will not care about this product in the future." In my opinion, this is wrong, and the most likely result of a launch isn't "This is bad. Stay away" but "I don't care".
The truth is that you are launching to learn from your early users. It's unlikely you will impress them, but you may get a few hundred to care enough to tell you what is good about your product and what is not useful. Airbnb famously launched three times because nobody cared the first two times. But the team learned a lot from each launch.
Looking at Airbnb's growth, I would assume the team had many great ideas to develop. How did you effectively choose what to build, no matter how good a new feature seems to be?
This is one of the most important questions for any growth and product team.
To simplify, I would say this: For companies that have product-market fit, you want to spend more time optimizing your funnels/loops in your products than you do building new features.
I would say spending two-thirds of your time on optimization is an ok ratio. In the early days of Airbnb, we spent way too much time building new features, many of which were not used and overlooked things like optimizing search conversion, authentication, booking conversion, listing your space conversion, etc.
The latter was the most important work for our growth, and building new things was less important. The downside of too much optimization is that you will hit a local maxima. You need the experience to know if you've found that.
At Airbnb, when entering new cities, can you talk through how the team "designed" early supply? For example, did you target specific neighborhoods or specific types of apartments? Did you start with user-segments or personas on the demand-side? How high a bar did you set for early supply quality?
I think the most critical thing you can do is to increase friction. You only want a high-quality supply. That requires them to upload photos, verify their identity, write a description and get the details of why it's a good listing.
In the very early days, we had nearly no friction, and I believe that was a mistake we later fixed. To build trust on the platform, people need to give up information, so they don't treat Airbnb like another classified site.
Out of your Airbnb experience, when would you recommend to raise a seed round for the travel P2P marketplace? How much should the check be to maintain sustainable growth?
I think raising a seed round depends on a lot of different things and not merely on metrics. At the seed stage, it's usually just a bet on the team and, to some extent, on the market. What I would look at as an investor is how much the customers and the supply love your product/marketplace.
I would look at a combination of user stories and retention data. I would also look at how important word-of-mouth is as an acquisition channel. It's often a good proxy for a good product. Here's one of my favorite talk about fundraising.
Geoffrey Keating on February 6th 2020
G-Loot’s Chief Intelligence Officer, Jamie Dunbar Smyth, had a clear goal when he started using Segment:
Become an organization that makes decisions based on data.
See, the team at G-Loot — a global esports platform based in Stockholm — wanted to better understand their players. Everything from acquiring them to retaining them, and keeping them coming back for more. They also wanted to bring rapid-tempo testing and iteration into their organization.
The idea behind the move, according to Jamie, was to create autonomous teams that could run fast, adapt to changes, and do what they need to do.
“_We have extremely aggressive growth goals and the only way to achieve our KPIs is by truly understanding our players. To do that, we need clean, consistent, and credible data, stored in one place, and with enabled integrations of the core tech stack to act upon the data.”_
Since using Segment in late 2019, G-Loot has become a company rooted in data. They’ve replaced wasteful big bets and guessing approaches with more consistent, cost-effective, and repeatable processes. And they’ve armed their product teams with a way for people to act on data quickly and easily.
Here’s their story.
For many fast growing startups like G-Loot, the default approach to growth is to “throw spaghetti at the wall”. Blindly try out a bunch of tools and tactics and hope that one works. Instead, they wanted teams to put players at the center of everything they do. For example, one team would be focused on increasing value-added actions for players. Another would focus on data-driven personas for marketing outreach. All of which require a top-notch tech stack.
This was easier said than done.
When Jamie arrived at G-Loot, what was in place was a very basic tech stack. This posed a great problem for an organization wanting to shift into rapid and continuous product iteration. G-Loot had been relying on a limited infrastructure for its organization to track events and pull player insights. They had to run all custom development to get actionable data, which burdened developers and stalled product roadmaps.
“We relied on one BigQuery warehouse collecting data through a custom ETL built by the back-end team. The warehouse was useful for financial reporting, but the team struggled to pull behavioral insights that would help them create more personalized experiences for our user base.”
To create a fully integrated culture of data, G-Loot needed three things:
To get actionable insights from their data quickly and easily.
To unite the company around these insights.
To make product and business decisions based on the data.
To choose the right tool, Jamie uses what he calls the “Picasso model”. In short, look outside your field for inspiration. His inspiration was the tech stacks of some of the fastest growing companies in the industry - Pinterest, Slack, Airbnb, Uber etc. As he was browsing through the stacks on StackShare, one name kept cropping up over and over – Segment.
By researching best of breed tech stacks on StackShare, Jamie found Segment.
It was clear to Jamie the team needed to give it a go. They started small, focusing first on their mobile team to collect player events. And a few days after implementation, teams started to see how Segment could help build better product experiences.
“We had dashboards up on Amplitude, with real product data via Segment, before we had even partnered with Amplitude. The office started saying, "Oh wow, what's this? Oh this is really cool, I really want this."
So they continued to broaden the scope, adding new tools to their stack that made data available for everyone. Jamie described the speed of integrations as key to standardizing data and unlocking resources in different teams.
For G-Loot, building on top of Segment also allowed them to create:
An input approach for teams to improve and enhance data.
A centralized data library to keep teams informed on new updates.
A way to test and build the best stacks quickly.
By the end of 2019, G-Loot had its full-stack in place, and Segment was now the core of its infrastructure. This allowed all teams to leverage information they require, enable feedback, and ultimately, put people in the driver’s seat.
As Jamie describes it:
“Our mantra is to treat data as a product. There’s now an entire data ops approach in the business. We can make sure that when the product evolves and we create new events, there’s a clear process to make sure they aren’t forgotten from the development process.”
When someone wants to add a tool to G-Loot’s new tech stack, the first question Jamie asks is:
“Does it integrate with Segment?”
Because Segment connects with their core tools FullStory, Optimizely, Google Analytics, Braze and Amplitude, the G-Loot team was able to immediately improve on their products. That’s because teams who use Segment can learn about how their products are used, and iteratively build-in better features.
At G-Loot, every team from mobile and payments, to marketing and business intelligence, has data piping into Segment, with some incredible results so far. We’ll leave the last word to Jamie:
“Since adopting Segment, clickthrough and conversion rates have doubled on average. For the games we promoted, clickthrough rate was in excess of 10% and sign-up conversion rates have tripled.”
Doug Roberge on January 30th 2020
If you want more details on what’s discussed below, check out Lex’s Growth Masters lesson.
Before we get started with the interview, let’s quickly review what exactly we mean when we say “growth designer.”
A growth designer is a job role in product development teams with a multi-disciplinary focus centered around ideating and implementing product changes that build virality and growth into the fabric of the product. It’s the job of a growth designer to help product managers and design teams build a product that will inherently drive adoption and growth.
But, how exactly does this role of growth designer function in a scaling company? Check out our interview below with Lex Roman to find out.
I've helped several teams through this transition. Starting with KPIs is a good approach. It's easy in the early stages of a company to work off assumptions about customers and their behavior. But as your product and userbase grow, it's more and more important to build up evidence for your decision-making and work towards this transition.
A few tactics you could try:
Defining goals together so everyone is bought into them.
Establishing a working group to help figure out how you'll approach measuring goals (choosing tools, instrumenting events, data capture).
Running some exercises to map out what you know (even if only qualitative customer feedback) and what you need to learn.
Leaning on customer development (interviewing customers) as an input into product output while you build up your quantitative measurement.
One way to approach this is to bring folks together in a working group. Invite a small group of stakeholders from across your team and define some goals. You can assign a couple members of the group to try some naming conventions out and bring back ideas for discussion. Then, try the naming conventions out on your existing events. See how they work. As you go, you can share out progress with your wider team to invite participation from any passionate contributors.
As far as migration, I would recommend not doing it all at once. I tried that and it nearly cost us several teammates. Start with the events that are most used AND most poorly instrumented. Just work in one area of your product at a time. When renaming events, I like to send duplicates in for a period of time to ensure accuracy (aka send the old name and the new one). Then, after a couple of weeks if data looks good, document the change in your taxonomy.
I see this all the time. As new products or features keep popping up, it's really challenging to make sure everything's aligned across tools. One way to do this is to ensure that everything has an owner. One thing that happens at large companies is that someone instruments something, like a new tool, and then no one owns it. I see it happen over and over again, where teams are paying a ton of money for tools that no one owns inside their companies. Then, they end up sending garbage data to it and then they end up not being able to use it at all. Ownership is key.
Lex’s data ownership model. Download the worksheet to fill out yours.
I often point to Airbnb's Data University as the gold standard of internal training:
Airbnb’s Data University Curriculum
Even though most teams are not at that scale, there's a lot to learn from their approach. I especially loved that they met their teammates where they were on data literacy.
I've worked with some tiny teams and we've been able to achieve a lot of knowledge sharing through:
Creating a single place with all data documentation.
Holding monthly trainings to help new teammates get up and running on our tools.
Establishing a Slack channel for data questions.
Pulling together a list of the most relevant documentation from the internet (for example, I always tell people to use Segment's Analytics Academy)
Making it clear who to go to for help
This answer is similar to the above question, but I would add two things.
Make it really really easy for colleagues to get help with data. Offer office hours. DM people when they ask for data access and offer to help them make a visualization. Be patient with folks. When you lower the bar to using data, more people will use it.
Show your work. When you are writing a query or making a chart, explain what went into it. Or walk through it live in a working session. Teach your team by example.
I've seen a lot of mistrust of data. And I've definitely seen some folks share some sloppy charts.
On the mistrust side:
Document their concerns and see if you can investigate them.
Then, go back to them with what you learned and see if you can build more trust.
On the misuse side
Sometimes, you can gently ask questions to ensure data is being presented fairly. "Walk me through how you created this view" or "Can I ask where this number came from?" are good places to start.
Other times, it might just be worth letting it go depending on the stakes. Relationships with your teammates are often more important than bad data.
I actually answered this in detail in Lenny Rachitsky's growth newsletter, but I will summarize it here:
Define metrics together
Review metrics together
Reflect on releases together
I rarely see teams reviewing their goals every week or so when they plan work. Doing this will really help your team get comfortable with what they are looking at and why. It will also encourage questions and interest in learning more.
The biggest mistake is not talking to your customers. I see this over and over from founders and from designers. Being able to accurately source and build relationships with your customers to understand their true behavior, situations and attitudes is the key to solving for them.
If you are talking with customers often and truly understanding where they are coming from *before* creating solutions, you will be much closer towards an experience that is meaningful and valuable.
All the time – how much time do you have? : )
Most of the A/B tests I've run are inconclusive which is not optimal and can make decision-making really tough. I've also had several tests fail spectacularly. Those are more fun but also demoralizing for the team.
Here's one of my favorites.
At an e-commerce company I worked at, we ran a test to add a shopping cart into checkout.
Usually, when you buy stuff online, you see what you're buying during checkout. This company wasn't previously showing that and it was resulting in a lot of issues with orders. We also had a strong hypothesis that it was causing people to abandon checkout.
I did several design iterations and ran usability interviews with them. I was pretty close to customers so I took a lot of their input into account.
But when we ran the test, it tanked. Within hours, which was incredibly fast for the size of this cohort, it lost by a landslide.
The team was heartbroken but we picked up the pieces and deconstructed what went wrong.
First, I dug into the analytics. I went through every single user path to see if I could find errors people hit. I also wanted to understand where they went after abandoning checkout.
Second, I reached out to interview the test cohort. I didn't have much luck but I got a couple interviews and some email replies that helped clarify the issue.
What we learned, in the end, was that this new feature was actually highlighting issues that needed to be addressed earlier in the user flow. With this information, we were able to properly prioritize fixing some of the earlier issues with the cart.
Lastly, I'll offer one piece of advice from a data scientist I'm working with now.
As you write your test plan, play forward the results. What will you do if it wins? If it loses? If it's inconclusive? Thinking through this early can help avoid bias and assumption-based decisions later on.
Growth UX is a UX practitioner focused on growth. Some folks say all UX is focused on growth and that's absolutely not true. Some UX practitioners focus only on users and may not solve for business growth.
It's important to call out that growth UX is not practiced alone. To achieve growth, you need a cross-functional team of some kind, of which UX is a piece.
Regarding how this fits into teams, it's still unsolved. Some companies establish a growth team. Some establish more than one growth team. Some spread growth responsibility onto all teams.
On a small team, I've seen UX practitioners work on a mix of general product work as well as some growth initiatives. In this case, they usually sit on a product team.
The change I'm paying attention to is designers getting more involved on the business side.
Growth design is a part of that, though there is plenty of design work that is business-focused but not growth-focused. For example, a money-saving project is business-focused but won't grow the business.
For UX practitioners who want to get more involved in business, they need to learn more about:
business models, how businesses make money
strategy (both product but also overall market strategy)
I hesitate to give this a name. My hope is that design as a field becomes more business aware and that it's less of a specialization in the future. Regardless of whether or not a designer has all the skills I listed above, I believe all design should solve for both users and the business. I think we are moving rapidly toward that future.
Focus teams on explicit, singular business goals. Source.
The first thing I'd do is get the lay of the land. Talk to everyone you can. Document everything you learn. Diagram how the data is flowing and where any issues might be
You have to do this thoroughly and thoughtfully to build trust and truly understand what's going on.
Then, I would review what you learned with your key stakeholders (probably data or product leaders). Ask them to confirm that your read is accurate. Make a recommendation on where to start.
As far as what to tackle, I would tackle any red flags first. Red flags are data outages, broken tools, broken events, broken pipelines and sensitive user information flowing into tools.
Second, I would tackle any major points of confusion. Cut unnecessary/unused tools. Remove or hide unused events or data being captured.
Consider writing some clear documentation on what's reliable now and the plan for making the rest reliable. Break it into small pieces of work. Include your team along the way.
It's super exciting that growth UX is a thing now! The first thing I'm seeing is much more awareness that design is a critical component of growth. The amount of roles I see for designers and design leaders focused on growth has tripled this year.
Another trend is an increasing focus on growth in product teams. Designers working in growth can work on marketing, product or even sales. I am seeing more product teams focus on growth and as a result more product designers are becoming growth designers.
Lastly, I'm seeing a lot more designers involved in data. I've even seen roles for designers on data teams. UX designers can offer their human-centric approach to data infrastructure and operations. Previously, data has been left to those with PhDs and strong math affinity, but when UX practitioners can get in and make data more accessible, it can transform how a team uses data to make decisions.
In my initial blog post defining growth design, I highlighted Airbnb and Headspace, both of which have some fantastic growth design.
I think Instagram does a pretty great job of marrying growth and product. Their core growth action is "following" and that's also something most users want to do.
Anytime a product can build a growth loop that functions off its core value proposition, that's when you've really nailed growth design. When you don't need to create a referral program because your growth loop is naturally part of the product experience, that's when you know you've got something.
If you want to access more AMAs like this and ask hosts questions live, sign up for Growth Masters now.