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.
