Michelle Sun San Francisco

// Lessons learned so far from our transition to growth at Buffer //


Sean Ellis detailed at the Growth Hackers Conference on three key stages of growth(1).  With his experience working with various startups including Dropbox and Eventbrite, he coined a concept “Growth Pyramid”, from product market fit, then transition to growth, and eventually, growth.   

At Buffer, in recent months, we have been focused on the transition to growth.  This post intends to share some key lessons learned so far.  I hope it will be useful for other startups at a similar stage. 

Growth hacking is what you do only after you have growth. You need to prove out that you have a core value prop, an asset that people like and use. ” 

- Keith Rabois, former COO at Square  


(1) Define and refine product goals

"What is the core value that the product delivers?  What is the wow experience (or "aha" moment) that we want the user to experience?"

The foundation of growth is delivering real value.  Hopefully these are obvious questions that you can readily answer.  In all, it goes back to what and whose problem are you solving.  The answers should be short and simple, and can be explained to someone that is not in the domain / industry.  I find it helpful to go talk to a few friends who are not in startups, and refine after each pitch until they understand right away in one description. 

(2) Understand existing behavior

"How are people using our product right now? How are previous level of engagement leading to subsequent usage?" 

Before starting to actively track metrics, you need to know what metrics should you be tracking.  That is something we come across when we were about to make a dashboard for internal reference.  

Exploratory analysis is useful in uncovering usage patterns, similar to Facebook’s 7 Friends in 10 Days.  Andrew Chen has written up a great blog post on how to get those insights for your own startup. 

At Buffer what helped us got up to speed was whipping up a simple excel spreadsheet.  Choose any tool that is handiest for you at this stage; the goal is to make sense of the numbers quickly.  At the end of this step, you should know your company’s funnel metrics and current trends for each off top of your mind.  

(3) Segment and implement user analytics

"Which users are most active? Eg, for users that signed up on iPhone or Android, how is their behavior different?" 

Once you have a fundamental idea of how the macro level product usage looks like, it is time to look beyond aggregate data.  Segment data to answer more specific questions.  For example, when segmenting the activation rate of signups from different channels, we discovered that activation rate on our web dashboard almost halved with the re-design back in December (while iPhone activation shot up!).


This is also a good time to implement user analytics.  Storing events for each user systematically is an investment that pays off.  For example, if you’d like to answer whether users who have received a certain email newsletter are more likely to upgrade or not, user analytics provide a straightforward way to query against an existing, nicely structured database. 

(4) Start running experiments

Velocity and data can change the company culture.  You don’t have to finish all these analysis to start running experiments.  It is a virtuous cycle where experiments can drive more understanding on the existing data as well.  We have seen speed of rolling out experiments picking up since we started to have at least one experiment running at a given point in time.  


Other things to watch out


Keep track of all questions and experiments.  Exploratory analysis involves looking into user behavior and running different types of analysis.  By definition, some of these analyses may yield interesting insights and most do not.  Don’t despair; keep a log of questions the team asked and the results for each analysis.  Often, hypotheses change in a product, user behavior can evolve and it is useful to reference back past analyses and experiments.  

Set a deadline for exploratory analysis.  There is always another way to slice the data. There is always a better way to build a churn prediction model.  Start running experiments anyway!  When transitioning to growth, think of these analyses more of hypotheses that should be revisited regularly. 


Is your startup also at the stage of transition to growth?  What are some of the key lessons from your transition? 


(1) For more extensive notes on Growth Hacker Conference and on Sean Ellis’ presentation on Growth Pyramid, check out this blog post by Sandi Macpherson on Quibb.

Special thanks to Joel Gascoigne for reading through earlier versions of the draft. 

Background to Sean Ellis’ “stages of growth” chart, credit to Thundermark

// Common Pitfalls in Building Products and How to Avoid them//


New year is a great time for reflecting past year’s learning.  In 2012, I brought a product from ideation to market, acquired customers for it and implemented features from customer development of Lean Startup model.  I realize, there are a few common pitfalls that first time entrepreneurs, including myself, are prone to fall prey to, and how I would do differently in the next product. 

Training the empathy muscle

Building a product that people need requires a thorough understanding of customers’ values, priorities, perception, tolerances and experiences.  

Common pitfall: assume the same technological proficiency from ‘regular people’ as ourselves.  I find it helpful to speak with friends and family in different industries, such as my sister in the healthcare industry who owns one page of apps on her iPhone 4S and my high school friend who works in airline marketing who only recently opened a Gmail account.  

You may argue, the best products are those that solve the creator’s own problem.  It is true that solving our own problems helps us see the users’ (ourselves) need more clearly.  However, to make the user interface accessible, we still need to step out and think about the product from a beginner’s eyes, respect and cater to users’ technical understanding.  

Product discovery 

Making software products is a two-stage exercise, figuring out what to build and building it.  During the product discovery process, the team flushes out ideas, tests out new technologies, thinks about long term, short term product direction.  Once the team is done crafting a winning product, the focus shifts to execution. 

Common pitfall: product discovery is often treated as a scheduled task like building out a feature.  That is because engineering talent is often the most expensive asset in a startup and once received funding, startups are pressed to build as quickly as they can.  That can often be a blessing in disguise; most startups should place emphasis on product discovery and maximize learning, instead of building. 

Instead of believing “build it and they will come”, Marty Cagan, author of Inspired: How to Create Products Customers Love, recommends to focus on answering these questions:

     - Are there real users out there who want this product?  

     - Have we identified a market and how can we verify the opportunity with potential customers?

     - What is a valuable, usable and feasible product solution to this problem?

     - What technologies can I apply solve this problem in a better way?

     - What should the user experience be?

While there is no shortage of hard problems out there, the challenge is in discovering a valuable, usable solution to that problem.  That involves talking to a lot of customers.  To me, the biggest part was to learn how to ask good, open ended questions.  The goal is to learn as much about the potential customers as possible, how they perceive the problem and what are the constraints in finding a solution. 

Case study: Dropbox

After talking to venture capitalists who said they don’t use any of the cloud storage servers, despite the plethora of them in the market, Drew Houston, founder of Dropbox came up with 3 minute screen cast and received feedback from Hacker News.  The next step involved posting on Digg, to get more ‘general mass’ users.  By posting links on politics and humorous content, it attracts significant interest from the non-tech community.  All these were performed before shipping code.  His first demo video is posted below. 

Product validation

After discovering a potential solution to the problem, what follows is to find evidence that the product will be successful without building out and deploying it.

Common pitfall: to be over confident in a product spec, or an idea, and think they will adjust the product with the feedback they get when the beta version is out.  The beta version is often too late for major changes, and the time and emotional investment by the team while developing the beta product often make it costly, economically but also in terms of team morale, to pivot at that point.  

There are three types of validation: 

  1. Feasibility: Is the product going to be buildable, given time and funds available?
  2. Usability: Can users figure out how to use it? Present the prototype test in front of real people. 
  3. Value: What really matters is whether or not the product is something users will fund valuable and want to buy?  

Often, the road is windy with lots of false starts and resets.  In all, it is better to learn about the market early on than after consuming months of engineering resources.  For example, my previous startup Spotick went after the mobile loyalty space, which is a validated, large market with lots of sizable players.  However, the geographical market we went after, Hong Kong, was culturally less ready for a consumer product.  While the merchants were willing to try it out, we did not sense a willingness to pay.  In light of that, we switched to explore enterprise sales with retail and food & beverage chains, which we saw more demand and validated the value through securing marketing budgets with a handful of companies. 

Case study: Buffer  

Buffer's landing page serves as one of the best examples that I came across regarding product validation.  Founder Joel Gascoigne put up a landing page and showcased a “product’, and by checking the clicks on the potential pricing plans, he validated customer needs and willingness to pay - all before even building the product!  The details can be found here

Improve existing products. 

This is an area that I feel especially strongly about.  Once the product is out in the market, the excitement of having real users also brings in lots of opinions, sometimes contradictory, but equally passionate.  Which ones should we listen to, and when should we respond to feature requests?  

Common pitfall: to gather subjecting feedback, elicit customer requirements and chase features.  In my past experience of selling to enterprise customers, I remember clearly the allure of ‘adding just another feature’ to close the sales.  It requires a lot of discipline and determination to say no to the feature requests.  While it could feel devastating to turn away potential customers in such early stage, it is wise to avoid the slippery slope of becoming what Marty Cagan calls “feature factory”.  

A more fruitful pursuit is to focus relentlessly on the most important metrics and perform A/B testing to drive the metrics to the right direction.  

Case study: Skype

Skype was a prime victim of feature creep.  It grew from a basic communication tool to many unused, complicated features like Public Chat, Send Money.  A key sign that the product became too heavy and have too many superfluous features - releasing Skype Pro and Lite versions.  These features and products are now discontinued, as the company strives to return the product focus to core functionality. 


source: Skype Discontinued Features

What are the tricks that you have found useful in developing products?  What are the key difficulties in different stages of product development?  I’d love to hear about them in the comments!

Photo Credit: Collective Action Toolkit

It takes time to come across situations where you notice something missing. And often these gaps won’t seem to be ideas for companies, just things that would be interesting to build. Which is why it’s good to have the time and the inclination to build things just because they’re interesting.

Live in the future and build what seems interesting.

Many founders believe they are at a disadvantage to someone who knows how to write code. They believe they are not hackers because they are not coders. The truth is they might have a creative advantage because they won’t be jumping into code too soon. Instead, they’ll be forced to “hack” their ideas and test them using high level tools and platforms that will keep them at the level of detail. They’ll be focused on solving user problems, rather than solving implementation problems.

Hacking isn’t just about coding skills. it’s a mindset of getting things done while focusing on what matters the most at each stage, without getting lost in the detail too soon.

You need to be able to shift decisively from brainstorm mode into execution mode. It’s fine to pontificate about the big world changing vision. But, at some point, you need to clear the cruft and make a beeline to launch, then iterate quickly with real customers.
blog comments powered by Disqus
I work at Buffer on metrics/growth. Here I share about startups, personal improvement and wellness.
I'd love to hear from you!