Building features and products is hard, but it’s even harder to attract and retain an audience. Use these 5 quick rules when thinking about feature and product development, and ensure you build the right thing at the right time for the right audience.
Rule #1: Validate the need
Rather than starting with the solution first and then going to build mode right away, consider first validating the need for the feature or product in the wild using a simplified, more basic, or otherwise just-good-enough amount of development and polish to get feedback from actual users. Better yet – figure out how to validate the idea yourself without pulling in other resources.
How do you actually go about doing that? You need to start with a hypothesis and work backwards from there.
Rule #2: Use a hypothesis driven approach
A hypothesis is “a supposition or proposed explanation made on the basis of limited evidence as a starting point for further investigation.” In other words – take an idea, make an assumption based on some evidence, data, or qualitative input you’ve received, and pinpoint a starting point.
My hypothesis for the Mastering Growth series was the following:
The Mastering Growth series serves an unmet need for digital marketers, product managers, and other professionals to learn growth marketing from the ground up. By providing this series, I can positively impact this audience and their impact on their organization, as well as their career path while generating revenue.
This is a pretty big hypothesis and it’s important to note that before diving right in and building the program, I started very simply and validated the need for the series by talking to over a dozen individuals who all thought there was a gap in the market for this type of program, and that they could personally benefit from it. I used their feedback from the start to make the program better. But the starting point was my hypothesis that this need existed in the first place.
Rule #3: Keep it simple
Most hypotheses that you come up with for features will be a lot smaller. For example, you may have something simple like a button color change that you want to test before having engineering roll out the update. That hypothesis would go something like this:
By changing the button color from Red to Blue I can increase the % of people who visit my page and click the button.
We’ll revisit hypothesis a lot more in detail later in the series, but for now, start thinking about ways you can use hypothesis driven thinking for your own products and features.
Rule #4: Think beyond product
The way we think about (or don’t think about) the market is often wrong
While you likely won’t change how your company builds or thinks about products and features overnight, it’s worth being fully aware of some of the challenges that growth teams face if they are responsible for overall key metrics for the company – especially as more and more products or features are released. Knowing that most challenges are market based and not product based means that the success or failure of these product and feature releases often is the responsibility of the people working on growth. Therefore, it’s critical that growth practitioners think about the market, audience, and marketing early in the product build lifecycle.
Market sizing & overall goals and relation to product
Most great companies take over small markets. Take the time to think about how markets will evolve. You want a market that is too small now for any big players to take a look at, but will be big in 10 years. This is one of the big systemic mistakes in investing. They think about the growth of the startup itself, not the growth of the market. One of the big advantages of the small but rapidly growing markets is that customers are usually desperate for a solution, and they will put up with an imperfect but rapidly growing product. Sam Altman, Y Combinator
Store away that last sentence for later. People will put up with an imperfect but rapidly growing product.
Rule #5: Give more thought to marketing
Instead of relying on our assumptions to drive our product roadmaps, what if we looked holistically at the problem itself? Take the “we need this feature to round out our product” idea.
At the product level, here are some questions to ask yourself:
- Why do we need this feature?
- Who benefits from this feature?
- What might this feature detract from?
- What is our goal with this feature?
- How do we measure if this feature is working or not?
- What’s the simplest way we can validate this idea?
- How does this feature improve our ability to own our market?
Outside of the product view, ask yourself:
- What and who do I need to do to support this feature?
- Do I need to write content, emails, drip campaigns?
- What other parts of our marketing funnel does this feature change?
- How are users going to learn about this feature?
- What happens if this rollout fails?
When you move to this type of thought process, it becomes easier to break complex problems down into smaller chunks.
Interested in learning more about this process? Check out my “Growth Led Product Development” lesson here.