Step 1: Big Question Funnel

Product Development Step by Step

Step 1: Asking the right questions with the Big Question Funnel

When you have a product to develop, proper planning is the most important step, and proper planning begins with asking questions about the product.

In order to ask the right questions, think of a funnel. At the top of the funnel are the most generic and highest level questions, and the deeper you go down the funnel, the more specific the questions get.

Let me explain...

It is important to ensure that all stakeholders of the product are aligned on 3 major things:

The purpose of the product
The target market
The end user of the product

The best way that I have found to align the team and stakeholders at the beginning is to have everyone hop on a video call, share a document with most of the questions already written out, and discuss and write answers from top to bottom, one by one. Each question is designed to get narrower and narrower and by the end of the document, everyone should have a shared vision of the “what/why”, “how”, and “who” of the product.

Big Question Funnel

What is the purpose of this product? (1 sentence)

It is important to start with a thesis statement of the problem to be solved. This thesis needs to be one sentence. At the top of the shared document, there should be the first question: “What is the purpose of this product?” If everyone can come together and agree to the top level idea, then things can begin to be put into place. This one thesis statement should start to define the “what” of the product.

How will the product fulfill the purpose? (4 sentences)

This is the development of the “how” question. This question is limited; it is not a list of endless possibilities and requirements, but is a short paragraph on high level ways the product can fulfill the above thesis statement.

Who is the product trying to reach? (persona)

With the high level “What” and “How” questions out of the way, the "Who" question is the next to be defined. Try to define ALL the users and potential users of your product.

With just a few simple statements, we have defined the market that the product will be competing in, how it will reach the users of the product, what kind of sales and marketing are needed, and practically the entire business model of the product.

Categorizing Market Segments

Now, let’s take a slight divergence from the original “big question funnel”, and talk about categorizing market segments. With much thanks to Christoph Janz for developing this concept, we can categorize different market segments with cute animals. Each market segment is radically different from each of the other segments, and if you launch a product in a segment the wrong way, it can kill your company. If you are building B2C products, but try to sell them as B2B products, you will not succeed; the model must fit in the framework. What is this cute animal model you ask?

Well, let me explain…

Let’s consider how to build a 100M SaaS software company. There are several ways to build and sell 100M worth of software. The most extreme examples are to sell a million products at $100 each, or to sell 100 products at $1M each. The other models fit in between those 2 extremes.

Five ways to build a $100M EssA business.

This animal segment dictates what kind of sales and marketing you need to do. Mouse level sales needs virality to be able to maintain sales and is an extremely low touch sales process, and whale models need dedicated salespeople and demos and is an extremely high touch sales process. When looking at apps in a mobile app store, you would not expect multiple calls and demos with a sales person, and when an enterprise is thinking of purchasing a product in the whale segment, they would be quite shocked if there were no demos or sales calls, but instead they were presented an online credit card form.

If you are somewhere in the middle, how much your customer pays you per year ARPA (Average Revenue Per Account) will dictate what it costs to acquire new customers and if you can survive. For instance, if your product is a Rabbit, if there is a salesperson involved, it will probably need to be a “one demo/call close”. This is because at an ARPA (Average Revenue Per Account per year) of ~$1k and 30% churn, the CLTV (Customer Lifetime Value) will be ~$2800. If the CAC (Customer Acquisition Cost) payback is 18 months, and is split 50/50 between sales/marketing, that means that only ~$700 can be spent on sales to acquire a single customer.

The Rabbit model of business needs a very low touch model of onboarding. Most customers should be able to onboard themselves and not have to have the product specifically customized for them to be able to make quick use of the product. Most of the sales will need to come from inbound leads, because there is not enough budget for salespeople to make multiple calls and demos with the same customer.

Going Deeper

Since I do not know what kind of product you will be developing, I can’t be more specific, but depending on the product, I find it makes sense to dive more into the “who” question a bit more. Except for the most simple of products, most products have more than one type of user. A good next question to ask is, “What are ALL the user personas that will be involved in the product?” Sometimes if the product is B2C, the answer is (only two):

internal admin
end user

Often the answer is much more complex, especially if you are building B2B or SaaS products. Some of the potential users of the product could be:

internal admin
internal user
internal support
external account owner
external manager
external employee
external additional users

When building complex apps, there could potentially be many more! With added users, comes added complexity that needs to be defined from the beginning. Many of these users will have different permissions and functionality that need to be defined.

Some of the different roles might need access to audit trails, account management, payment processing, internal onboarding, etc. Other roles might have “view-only” permissions. With every single role, you should write down and define, “What are the most important pain points for this user?” This will help you think through what each user should be able to do, what their workflow looks like, what information they should see when they log in, and what features need to be built, shown, or hidden for each role.

As you start to determine what each end user needs, you should also determine what kind of responsiveness is needed for each user. Will they primarily be using the product on a desktop, mobile device, tablet, or will the product need to work on a combination of these?

By now, after a few questions, and a lot of discussion between the stakeholders, everyone should have a clearer picture of:

The purpose of your product and what it will do
The end users that your product will target
The market segment where your product fits in
The business model of the product
If the product will be sold through high touch sales or low touch customer onboarding
The different types of users that will use your product

What Is the ___ User Workflow?

From here, the next step is to develop user stories and workflows for each of the users that were identified earlier.

For each of the users, write down “What is the ____ user workflow?” Begin to develop a bulleted list of what a typical end user would want to accomplish. If your product has several different use cases, make sure each of these cases are documented.

For example:

Write out what it looks like for an “external manager” to onboard an “external employee”
Write out what the payment process looks like for the “external account owner”
What does moderation or support look like for the “internal support”
What steps are needed to cancel the product
What does it look like to accomplish ___ (main feature)
How will an “external employee” customize the product
What will a dashboard look like for an “internal admin”, etc.

There is a lot of writing, a lot of thinking, a lot of processing, and zero code and zero design so far. This is by design. It is much easier to change things when they are just words on the paper, and much more expensive when things have already been built.

What External Services Need to be Used?

Now that there is a pretty clear picture of how the product should function and who will be using it, it is time to start determining what can be reused, or if anyone has built out anything to make product development easier. Write down in the shared document, “What external services need to be used?”

For example:

Does the product need to send SMS messages?
Send bulk email?
Use social login?
Integrate with chat?
Process credit cards?
Integrate with CRM or other services?
Need to be hosted on external servers?

How will this product be priced?

Finally, now that most of the big questions have been asked and answered, and the target market has been picked, you can now start to determine pricing, packages, and tiers. This pricing estimate only needs to be an order of magnitude estimate; do not worry about being too exact. Is the product going to be in the “$100 per year Mouse”category, or is it going to be in the “$1M per year Whale” category? When you have figured out which animal category your app belongs to, you can start to determine what features your end users will expect at those price points.

If you are building a B2C app for a mobile app store, your end users will expect a simple sign-up and low touch onboarding process, they are not expecting a salesperson to come by and take them out to lunch. If you are selling to the larger animals, and more in the B2B category, you should start thinking about what features will be needed to win enterprise customers.

There is a very good chance your product will be sold in multiple tiers. Start to write out what features will be included in beginning, middle, or high level tiers. Even if the highest or enterprise tiers will not be sold immediately but down the line, it might make development easier to start building the application for multiple types of users or an audit trail.

One other important thing to write down and determine before building is how you will charge for the product. Will the product be sold based on usage, or based on the number of seats, or will it be unlimited, or based on features or some other combination? Determining how to keep track of these, or if they need to be tracked at all will make a difference in development.

Final Thoughts

When thinking about developing a new product, it is important to start at the high level, and work your way down the “big question funnel” to more and more specific questions. The initial discussions should not start with colors, design, logos, programming language, or any of the more fun things to think about. Those are great things to think about, but not until many other specifics are hashed out.

By following the “big question funnel” all the stakeholders should have an agreement and understanding of the “what”, “how”, and “who”. These big questions determine everything. If there is a mismatch between any of the answers and your business model, there will be pain. It all has to flow together.

This was not talked about, but it is also important to bring in your end users to get their opinion and ask them questions as well. You can build a beautiful product, but if the end customer is not willing to pay, or the product does not meet their needs, then you are out of business.

Need Help?

Do you need help with this process? Does it all sound good but you would like a hand in the journey? Send me a message and I would be happy to help lead you through the process. Tempered Root can help every step of the way, from leading you through the “Big Question Funnel”, to programming the product that was planned.

Tempered Root is a full stack software development company. We can help you refine your ideas and make them a reality. We help walk you through each step. You can be confident that your product idea has been thoroughly thought through.