Category: Startups

Who is the most aggressive person in your company, driving the hardest to hit your goals?

They say the most aggressive person should be the head of growth, with #2 being the CEO. Growth teams should be so aggressive and autonomous that the only person reeling them in is the CEO.

Your company picks a goal and knows how to move the needle by building a map of the product, analytics, and marketing. You come up with new ideas and triage by cost, benefit, and risk. Next comes execution. Execution needs to be aggressive and parallelized to drive as much learning and experimentation as possible. It’s a race for your life — your startup’s life.

So how do you do it? This is actually a question about how you organize your teams. It’s a question of company culture. We’ll explore these ideas in this post.

Growth Team vs Growth Managers

Should you have a growth team? Or should you have people responsible for growth on individual teams?

For a small startup, the answer is easy: the CEO is the head of growth. You need to know you metrics inside and out. You need to understand the strategy to get traction, and you’re probably the one executing on that mission. You need to deeply care about your customers and understand what makes them tick.

What about larger organizations? The answer isn’t obvious and it probably depends on how your current company is organized.

If there is a dedicated growth team, who triages the product roadmap for other teams? What rubric is used in that triage if not hitting some clear objective? Who owns the metrics?

If you have individual members responsible for growth, how do you test bold new growth ideas that take dedicated resources? How are lessons learned shared across your organization?

When designing the shape of your company, the important part is understanding these tradeoffs and making your objectives clear. You should experiment with changes that fit your company and see what works best.

In-House Growth Consulting

If I were joining a new company without a strong focus on growth, where might I start?

I’d go to every other team and ask two basic questions:

1- What are you working on?

2- What do you think will happen when that launches?

It’s shocking how many companies don’t ask such basic questions. There are a myriad of excuses — maybe focusing on quality over performance. Maybe thinking that a lack of corollary makes predicting the future hard.

Call this out. Prediction is hard, but that’s no excuse.

Going through a product development cycle with these questions in mind gets a company on the right track. After a launch, did things go as expected? Why not? What did we learn? What can you do next time? How can we organize our team in a way to deliver better results? If that worked, what can we do more to double down?

This is how a growth team thinks. Start by asking your product leaders some basic performance focused questions and keeping score.

Analytics Life Blood

Growth teams must make informed decisions to win. Early on, this might be qualitative data from talking to customers. At larger scale, aggregate behavioral data speaks volumes.

How are questions answered in your company? Put aside the mechanics, though they do matter. This isn’t about your analytics tech stack. If someone on your team has a product question, what do they need to do to get an answer?

Can they get an answer themselves? Do they need to be in good graces with Bob running the analytics servers? Do they need to know SQL? How are questions triaged? How are answers shared?

Build an organization where the cost of asking questions is as low as possible. Friction means some questions just won’t get asked and you’re on track to building a culture where data, even anecdotal from customers, isn’t needed to make decisions.

I’ve seen different organizations deal with this in different ways. Certainly there are instrumentation and exploration tools that can be bought or built to enable teams to answer questions. The collaborative side to these tools is the most interesting.

Dropbox at one point built a system jokingly called Coura. It was simple: ask a analytics question and say why you want to know the answer. When someone was ready to work on it, the system asked if the information was still needed. Anyone could see the other questions asked and their answers. Engineers were confident that the work they’d do to run an analysis was always needed and impactful.

At another company I helped, they built a system for managing complex queries over large data sets. One interesting byproduct was the ability to see the queries others were asking. This become an onboarding tool for product analysts. It wasn’t treated as such, but the teaching and sharing power was incredible.

Such social tools within organizations aren’t developed enough.

There are many vendors selling analytics tools and and business intelligence solutions. Their sales process and user interface distract you from the main issue in deciding what to use:

Product Needs Drive Analytics

Way too often, product teams dig into analytics tools and try to learn what the hell is going on with their product.

This is backwards. You need to start asking questions from the product side and answer in whatever way is possible. This often means writing custom code to get a real answer. This often means adding a new tool to slice and dice your data, or connect multiple data sources together.

Starting from the tool and working through questions doesn’t work well. The reason is that tools are general and not designed specifically for your company. They have a language, and not knowing your dialect means you don’t even think to ask your questions when you start from the tool.

For example, Google Analytics is very focused on pageviews. It doesn’t focus on users and their actions. If you started with GA, you’d be asking the wrong questions and working towards the wrong goals. If you focused on your product and users, you might then instrument the product with something like Mixpanel, and focus on what is really going on.

But even Mixpanel has some strong opinions. They are great at funnels and events. But if you launch a new feature and want to know how that affects retention, their cohort analysis tools aren’t as strong as Amplitude, an upstart analytics tool that focuses a lot more on cohorts.

Whatever the tool, the point is that you should focus on what is really going on with your customers and your product. Trying to understand that will yield questions that some tools can answer and others can’t.

Company Wide Performance Sharing

Some companies are really tight lipped when it comes to performance and revenue. The tide is turning here because there are huge benefits to sharing this information.

One of the easiest ways of building a more data focused product culture is to share performance data.

Dropbox did this with a daily metrics email. They built an in house metrics dashboard, and then took a daily snapshot and emailed it to everyone in the company. They included investors as well.

This has a huge impact on a company because you make what you measure. If you are measuring and sharing growth numbers, everyone in the company will internalize and represent those goals in their work.

This focus on performance was pervasive at Facebook. The whole company understood for years that the goal was to get everyone in the world on Facebook.

Product Specs Run Like Experiments

After you’ve triaged your growth, my specific tactical advice is to run each task as an experiment. You don’t need a PhD — just treat it like a 4th grade science experiment. Write down what you think will happen — something measurable that you can look at after the experiment. This is often a specific metric you hope to improve.

It’s crucial to reflect back on why your hypothesis was right or wrong. Digging into this helps you learn about your product and customers and informs your future product roadmap. We’ll cover this idea more in our next post about growth.

I really like the framework that Brian Balfour has put together here. Check out his talk here about how to run this experimental progress.

Putting It All Together

This is the fourth post in a series about growth. Subscribe here to get the next post right in your inbox.

1-  Pick a Goal

2- Map your Product to your Goal

3- Triage by Cost, Benefit, and Risk

4- Aggressive Parallel Execution (hello there!)

5- Keep Score (coming soon)

We’re also putting together a class on growth which covers this whole process and more. This will launch in a few weeks, so subscribe to learn more.

So you’re trying to grow your app. You have lots of ideas. How should you triage?

We’ve written that Step #1 is picking a goal. Step #2 is building a map to understand how your product features and marketing can improve your goal. Then what do you do? This post is the next in our series about how to grow – subscribe to get all our growth posts here.

In short, come up with ideas and triage them by cost, benefit, and risk. It’s important to get the details right here so you’re running valuable experiments, so let’s dig in.

Crafting Ideas

My favorite nonfiction book is “Where Good Ideas Come From” by Steven Johnson. It’s a natural history of innovation — describing the environments where that produce good ideas. There are plenty of ideas in the book for how to generate good ideas. Here are few.

Gather information in a liquid network. This means talking to users and people at your company that understand your users and your product. What would they like to see change? You’re not going to work on everything you hear — so just gather the ideas freely.

It’s important to capture the why and not just the what. Often people jump to a specific solution of the problem when the real insight is describing the problem itself. The best way to get to the bottom of this is just asking why.

“Add Facebook for signup.”

“Why?”

“It would make filling out this registration form easier”

“Why?”

“Because you’re asking for a lot! This form is complicated.”

Study the adjacent possible. That means look to see what is possible by putting different parts of the world together. The airplane was the adjacent possible of the craftsmanship of bicycle mechanics and a light gasoline powered internal combustion engine. The simplest example of this for your app is taking an existing flow and trying to improve an element: a call to action, the copy, images, or the design. Or take an email campaign that worked for a past feature and apply it to a new feature.

Copy fearlessly but study first principles. An easy source of ideas is to copy tactics that others have tried. The problem is that what works for others might not work for you. Another problem is that you might be reading the distorted view of an outsider. A good example of bad copying is the way mobile apps bury a prompt to invite friends in a sub-menu — just like Uber does. Uber is a supply constrained marketplace and didn’t optimize the rider invite flow for ages — but dozens of apps didn’t consider that before copying them. Again try to copy the *why*. For example, Dropbox used referrals because the product quality was very high and most users came from word of mouth.

Dig into your data. Besides talking to users, there are plenty of data sources to understand what people do with your product. Sometimes you can find interesting behaviors. At Dropbox, we analyzed the file types and found that photos were popular and numerous. Talking to users showed managing photos is hard. This kind of understanding can help you immensely when you have far too many users to talk to personally.

Don’t just optimize what is there. Some of the greatest ideas are really different than what you currently do. For example, you can generate lots of ideas by walking through web user onboarding and thinking about how each step could be improved. But the best idea could be something totally outside that flow, like a mobile app that doesn’t exist yet.

Distribute across focus areas. Growth isn’t just about user acquisition. You should be concerned with retention and engagement and virality. For YesGraph, we define categories like “developer onboarding” and “ranking performance” and others. Base this on the map you’ve built to know what parts of your product impact your core goal. Making sure you’ve thought about your growth from different angles is a way to encourage lateral thinking and have better ideas.

Triage by Cost, Benefit, and Risk

You don’t need to get fancy about the tools you use here. Just use google docs or quip to make a spreadsheet full of ideas. Use a spreadsheet because you’ll be adding different dimensions, and a flat doc isn’t the best format for such side by side comparisons.

There are three categories.

Cost: how many resources will this take? This means the time your employees spend. It could also mean a dollar cost for, say, an ad campaign. People might have a category too: this might be front end heavy, that might be visual design heavy.

Benefit: if this works, what do we predict will happen? Having a hypothesis before you run a test is basic science, but very few people actually do it. Make an estimate of the impact of your work. This isn’t expected value, but conditional on success.

Risk: how likely is this to work? If you already have an analog, you can have higher confidence a test will work. If you’re working on something totally new, there is much higher risk. An example of a very high risk effort is forking off a dedicated app from your main app. An example of a very low risk effort is testing the copy on a button.

Estimating the cost is probably the hardest part here because engineers are notoriously bad at figuring out how long something will take. The solution is to write enough detail about an idea so that each part is understood. Break down problems into component parts.

Spreadsheets are good for comparisons, but basic docs are better for more depth about a specific idea. So I usually have a doc full of stub specs. Eventually the stubs get their own doc for an even more product spec.

Balance Incremental With Potentially Explosive

80% of your tasks should be incremental, like running an AB test on an important form in your funnel. 20% of your time should be adding whole new, though risky experiments.

Incremental improvements matter over time. The reason is that if you’re working on the right things then the results are compounding. As we’ve said before, there is no silver bullet to solving your growth. You need to dig in and get to work.

Big risky, efforts can pay off, but being higher risk means that you are risking your company’s growth if you bet excessively on them.

The good news is often you can lower the risk by performing a small test. For example, adding a referral program has a lot of moving parts and takes some work to get right. It turns out you can validate the idea before digging into the hard parts. For example, you can literally add a single email asking users to invite others to see how your userbase would respond to a real program. Read this post for more details on referral tests.

What This All Actually Looks Like

I want to give an example of what this looks like, but a realistic view would require sharing too much of YesGraph’s internal roadmap. I love helping our community grow, but that is a bit too much transparency.

So let’s try something else. If someone wants our help in helping them walk through this process, get in touch: ivan@yesgraph.com. We can help you figure out the possible ideas and triage them. The caveat is that I’ll share your growth roadmap publicly.

We’ll see if we get any takers! What I can do is show what our internal docs look like – literally those pixelated images below.

I have one more thing I want to share here, but we’re not quite ready yet. If you want to see a more detailed breakdown of this process, subscribe to get future posts here.

This is the second post in a series about how to grow. Click here to subscribe to new posts.

The first step to driving growth is picking a goal. Then you need to understand your product to know which areas might drive growth. It’s about finding your growth levers. You should refine your understanding until you have a clear sense of how any change might affect your metrics.

Guided By Actual User Experience

To start, put yourself in the shoes of a user. What is the very first thing they experience? They might land on your home page. They might get a message from a friend about your product. They might have seen your company covered in the press. Start there, and expand.

List all the places where your product touches the user. Include every page on your site and parts of your mobile app. It is also email, push notifications, SMS, and other messaging channels. Some pages are about communicating what the product does during onboarding, others are part of the product experience.

You can go deeper by making it stateful. Where is the user in their lifecycle, and how does that flavor the experience. Often you have multiple goals for a single page, and representing those constituents is really important. While conversion on a landing page might be direct, most experiences after signup and onboarding have diverse targets. Over time, you’ll build up a better understanding of what specific actions cause a user to activate and be retained. You can then prioritize those features.

Map To Your Goals

Break down your product to understand how each part influences your goal. You can dive down to a microscopic precision here, but many people don’t even get the satellite view.

Let’s walk through an example. Your goal is more active users. That isn’t directly actionable, so what are the components? You have new signups, retained users, churned users, and resurrected users. Every single active user or previously active user belongs to one of those categories.

Now go further. Where do your signups come from? Some from direct visits to your home page, some from invites from current users. Understanding signup source is the first step to improving signups. The same is true for the other categories: how do resurrected users come back?

Back to signups, again go further. Through what channels are invites sent? What are the conversion rates by channel? What is the message? Is that email subject good enough to open the message? Is the body of the email enough to make the invitee click? Does customizing the landing page improve conversion?

Finally you have something actionable. You can run a test on the email subject and body to see how it affects clicks, and then invite conversion, and then signups, and then active users. You’ve broken down a part of your product from an abstract goal to something actionable.

Think of it like an expanding tree of detail. Here is one pass, but you want to expand on everything:

Now do this for everything, not just from the goals down but from the user experience up.

Include Uncharted Territory

The main challenge with this approach is that you focus on what is already there, but there is more to the story. You need to get creative and consider uncharted territory, things which you could be doing but aren’t. In the example above, you might be running a test on your initial invite. Are you sending a reminder? Do you reflect the status to the sender, asking them ping their friend directly? Do you use email when SMS might be more appropriate for your product? A good understanding of your product’s surface area should consider what isn’t there as much as what is.

Interestingly, when designers come up with possible implementations, they often have very different approaches. Too many times, I’ve seen these designs considered, filtered to pick one, and later on the product team is not sure what else to try. You already had variants, now just use them.

Too Much To Explore

It should be obvious once you break down your product that there is far more to improve upon than you can possibly do. If you’re running out of ideas, it means that you haven’t thought deeply enough about what you have and what it could be. The challenge becomes deciding on what to work on next. That is the topic of Step 3 in this series.

At YesGraph, we’re all about growth. We’re obsessed. We talk to so many companies about growth that we think we can help in lots of ways.

Our new growth product can help, but there is a lot more to talk about too. So we’re blogging about metrics and growth. And now we’ll start interviewing growth experts and startup founders building the future.

Introducing YesGraph Office Hours

We’re really excited to start publishing some of our interviews. This first episode dives deep into user onboarding with Samuel Hulick. He runs the amazing site UserOnboard.com – you definitely need to check out his product teardowns. We also talk about his new product, available at UserOnboard.com/beta.

Help us Launch This Podcast

We have a few episodes recorded, and need to finish up editing. We’re actually not in iTunes yet. We’ve been told that to best launch a podcast, you want a few episodes queued up. You also want friends to leave positive reviews to make your iTunes launch go as well as possible.

So if you like this episodes, subscribe to get new blog posts and episodes in your inbox.

The plan is to get the community to subscribe and review on iTunes after a few episodes are available. If you have any other tips of launching a podcast, let me know in the comments or email me (ivan@yesgraph.com).

Another way to help is to spread this post. Things you can do:

1. Tweet about it
2. Share with Facebook
3. Vote up the story on Hacker News
4. Like the story on Quibb
5. Vote up the story on GrowthHackers.com
6. Vote up the story on Inbound.org

I’m new to this, and the best way to get better is to get feedback. Do I talk too fast? Too many “ums”? Should I have asked our audience for questions before the interview?

Add a comment or email me with anything and everything: ivan@yesgraph.com