Time to read: 27 minutes

Summary:

I recently was challenged to think through launching a new product. This is a stream of thoughts, things I would think about and how I’d implement. I chose product analytics as the field. The field itself matters less than the thought process behind how to approach.

Below you can find an organized guide on everything I’d consider, think through and do before setting out to launch a new product.

Why take the time to do this? Because I like to learn. I’m always trying to get better at thinking through products.

I want to go very slow and deeply develop my thoughts on this, hash out choices and gather data so I can improve my own thinking. And document the entire thing. This will be quite long.

Because this is long you may navigate this guide using the table of contents:

Table Of Contents:

Hypothesis:

V1:

Product analytics are different than website analytics. For a website you might want to know things like:

  • total page views
  • duration of views
  • top referring sites
  • devices

For product analytics you want to know:

  • what features are being used the most
  • what percentage of people use the new features developed
  • what personas find the most value in {x}

SaaS products today either use existing solutions (not our target market) or nothing (BINGO).

Lots of SaaS products do not even know they can track this kind of data.

If we make it easy to track features and value delivered to end users our customers will make more money, and be willing to refer others to the service.

V2:

UPDATE: April 16 - After talking to some potential users, they are not interested in tracking product analytics outside of a few key metrics. This might be because of their small size the founders/ceo can run product and not need to justify decisions to their boss (and use data to do that). 1 commonality I have heard is everyone wants a segment.com like product, that doesn’t cost an arm and a leg. Because of this, I am going to alter the direction of the product slightly. Other changes will be made and reflected below.

Education Required:

V1:

If someone is unaware of the need for a product like this there will be significant education required.

  • Show a demo of website analytics vs product analytics?
  • Quantify the difference in data between the two?
  • Come back and add more thought out ideas.

V2:

Why do potential customers view segment as SO expensive they won’t purchase it?

Competitive Landscape:

V1:

The competitive landscape is complicated. There are quite a few players who’ve raised $100s of millions of dollars. They have 500+ employees and are attacking a different market.

When I looked into the market there seems to be 2 common approaches. 1 - freemium model with most important features removed from base or free tier or 2 - no freemium, enterprise model. I am not knocking these approaches at all. Just understanding the model being used currently.

V2:

I am not very well versed in this new product direction. I will revist at a later time.

Value:

V1:

I previously did not have a section on value but the core of our software is showing our customers how they can deliver more value to their end users so it would be wrong to not highlight how we intend on doing that, aligning ourselves with their success and some metrics we believe to be core to that assumption.

I specifically love this quote from Jason Cohen.

So I hit the meetings again — email, phone, in-person, whatever. I wanted to talk to anyone with a blog. Would they pay $49/mo if I fixed those three problems (security, speed, scalability)? What if I added a feature I had hand-built for myself (again out of need) — a push-button staging area so you can test changes before they go live?

The reaction this time was completely different. Some people said they’d pay $49/mo just for the staging feature alone. When the answer is “You had me at ‘staging feature’” — i.e. when just a part of your pitch is already enough — you know you’re over-delivering on expectations, and when you’re comparing those expectations to an actual price, you know you have market fit.

V2:

I believe customers $10,000ish MRR will pay some amount below $100/month to house their data and be able to integrate down the road.

Benefits:

V1:

  • Grow your software business faster
    • Know exactly what your customers value
    • Develop more features that deliver value to those customers

I am going to use the one above. The other bullets below were left over from brainstorming.

  • Focus your development on what matters
  • Build better products
  • Measurable data for your software business
  • Make more money with better data
  • Deliver more value for your customers
  • Grow revenue and increase retention through product analytics

V2:

  • Grow your software business faster by focusing
    • House all your data 24/7 and integrate into other services down the road

Freemium:

V1:

I have previously said I’d never build a freemium product but I think this will rebuke that.

Some notes on why:

  • lots of customers will be so small paying $50/month is prohibitive
  • customers will need to improve their software to find success (not incredibly easy to do in 1 day)
  • those who do improve software will love product and be willing to pay

Disregard everything above. Jason Cohen’s blog has swayed my decision. There will not be a free plan.

V2:

  • I think customers want to use a service like this, but are not willing to pay $x00/month at the stage they are at (10k a month or less MRR). Because of this, there might be an opportunity to acquire a lot of them and scale up with them.

Free Trial Data:

We will retain this modeling under v2 of this development

I listened to Tom Tunguz on the SaaStr podcast talk about his findings from free trial surveys of Redpoint’s portfolio. He shared some interesting data. This link seems to be a concise presentation of his findings if you’d like to read instead of listen.

  • Time and usage based free trials convert better than seats and features.
  • Conversion rates are not impacted by trial length. Shorten your trials.
  • Target 4% unassisted conversion (not involving a salesperson).
  • Target 15% assisted conversion (trial prospect talks to salesperson).

These learnings are great, and important to think about in this hypothetical product development and go to market strategy.

We will offer some sort of free trial.

We will offer a 60 day refund if a customer is unhappy. We will not offer a 14 day free trial.

Pricing:

V1:

Because of the reasons above I am thinking about doing something like 3 tiers. Entry, Hacker, Business. I have adjusted pricing based on our target ARPA. Previously the pricing started at $19.

Tier Monthly Active Users Price Per Month
Entry Up to 100 active users $39
Hacker Up to 250 $59
Business Up to 1,000 $149

I recently listened to Transistor.fm podcast, Build Your SaaS and they played a snippet from Jason Cohen. Jason runs WP Engine + did a lot of other interesting things before WP Engine.

Jason talks about how you can will your way to 100 customers, but charging so little that getting to a sustainable run rate will take 1,000 customers is next to impossible. To do this Adwords, SEO, FB Ads, etc, something will have to be working decently well.

It took WP engine longer than 2 years to get to 1,000 customers. And similar competitors the same timeline. We want to be mindful of this and plan accordingly. Charging $10 a month is unsustainable as a result.

We also will want to monitor our ARPA. We are choosing to track ARPA, instead of ARPU, because each account can have multiple users. Tracking users would be misaligned with our value targets.

I set our proposed pricing by using our financial charts below. If someone has 100 customers with roughly our same ARPA they will be making $5,000 a month. Charging $39 for the software to provide a measurable impact on their companies growth is cheap.

V2:

We need to refocus our value metric to better match our new product direction.

Financials:

We will retain this modeling under v2 of this development

Using Jason Cohen’s models we are going to set a few targets. In this hypothetical model the product would not be sustainable on its own until it reached 100 customers at an ARPA (average revenue per account) of $50/month.

# of Customers ARPA MRR ARR
10 $50 $500 $6,000
50 $50 $2,500 $30,000
100 $50 $5,000 $60,000
1,000 $50 $50,000 $600,000
2,000 $50 $100,000 $1,200,000

To reach our proposed target of $1,000,000 a year in sales we would need 2,000 customers (accounting for churn)

Jason in this talk lists WP Engine getting 25% annual prepays. This equates to:

75% x 1 (month) + 25% * 10 (months) = 3.25x

Some examples of this:

# of Customers ARPA Month 1 Cash
10 $50 $1,625
50 $50 $8,125
100 $50 $16,250

Customer Acquisition:

We will retain this modeling under v2 of this development

We are basing these numbers on Jason Cohen’s blog post, Fermi Estimation.

We are targeting a $1,000,000 run rate with 2,000 customers.

Jason in his model puts a ceiling on the number of people in the proposed product market at 1 million.

We will retain this modeling under v2 of this development

Assuming 1% conversion rate of qualified traffic to signups, you would need 200,000 unique AND qualified visitors.

Click through rates on paid traffic is 1% (AT BEST), so we will use Jasons number and say, .3%. so in this model we need 60,000,000 impressions on qualified eyeballs to hit our number.

Organic Acquisition:

We will retain this modeling under v2 of this development

Hardly any search terms have that much traffic, so we will need to find some other ways to drive attention to our product. We could also focus on organic traffic (blogs, tweets, podcasts, etc).

This still means we need to generate tens of millions of impressions. Ultimately, very hard if market is not massive.

Strategy:

We will retain this modeling under v2 of this development

Building a product that addresses 100m people has a shot at generating 60m impressions. So, it might be best strategy to find a market with this such reach.

Product Frameworks:

We will retain this modeling under v2 of this development

Next we start to break down some frameworks I think are relevant. I discovered the list here. You can use for yourself through that link.

Jobs To Be Done:

V1:

The first framework to consider will be the “Jobs To Be Done” framework. I explored the site Jobs To Be Done and discovered this highlight:

  • When [1], I want to [2] so I can [3].

Where 1 = situation, 2 = motivation, and 3 = expected outcome.

  • When I am thinking about how to improve my software, I want to deliver more value, so I can make more money.
  • When I am thinking about product roadmaps, I want to deliver better software so I can hit my revenue target.

The above statements are most relevant to our target market. The below fits more along a large team, and is better suited for the enterprise competitors mentioned above.

  • When I am managing the product team, I want to use data to back up our decisions, so I can get a promotion in the future.

This above will constantly be improved but is a start for now.

V2:

  • When [1], I want to [2] so I can [3].

Where 1 = situation, 2 = motivation, and 3 = expected outcome.

  • When I am trying to grow my software business, I want to track data so I can make smart decisions
  • When I am trying to track data, I want to retain everything so I can add other tools later
  • When I am trying to grow my software business, I want the freedom to add and remove tools, so I can better manage cash flow month to month.

Working Backwards:

The next framework I’d like to think through is Working Backwards, made popular by Amazon. More information can be found here.

Ian McAllister (Director at AirBnB) provided the following details about the Working Backwards method:

  • Heading - Name the product in a way the reader (i.e. your target customers) will understand.
  • Sub-Heading - Describe who the market for the product is and what benefit they get. One sentence only underneath the title.
  • Summary - Give a summary of the product and the benefit. Assume the reader will not read anything else so make this paragraph good.
  • Problem - Describe the problem your product solves.
  • Solution - Describe how your product elegantly solves the problem.
  • Quote from You - A quote from a spokesperson in your company.
  • How to Get Started - Describe how easy it is to get started.
  • Customer Quote - Provide a quote from a hypothetical customer that describes how they experienced the benefit.
  • Closing and Call to Action - Wrap it up and give pointers where the reader should go next.

He also listed the press release itself should be less than 1.5 pages. 3-4 sentences per paragraph, press release only focuses on what the customer gets. His rule of thumb is if the press release is hard to write the product is going to suck.

Proposed Press Release:

V1:

[PASTE IN FINISHED PRESS RELEASE HERE] ==> Press Release

So far, we’ve explored why someone might hire our product and what the press release we’d want to write at the end of the development cycle would look like. That press release is still rough but it is a start.

V2:

This should be updated but will be done at a later date.

Customer Development:

I am now going to reach out to Founders/CEOs I know who run profitable internet businesses to interview them about how they do this. In thinking through who the customers/users of this product would be there are probably a few different cases:

  • Owners of business
  • Product Managers (lead product development)
  • Product Marketing (market the features to x persona, y persona differently)
  • Technical team (actually write the software)

[Come back to once product is more developed and think through these segments]

I love Justin Wilcox approach to customer development and will be utilizing everything I wrote here.

Target Customer Interviews:

In keeping this list as comprehensive as possible the people I intend on reaching out to are:

Grouped into different segments but mostly bootstrapped/self funded with some exploration of different company stages.

Spreadsheet here

There are 28 people on this list right now. If I could get 10 solid interviews we would have some data to base our decisions on. I will be messaging most of these people on Twitter, and following up accordingly.

Customer Outreach Messaging:

I will add the cadence + example messages here once I get that far.

Customer Development Interview Questions:

I am going to explore the following questions:

  1. How would you describe your role as a business owner?
  2. What does success look like for you?
  3. What’s the hardest part about achieving that success?
  4. When was the last time you tried to solve that problem?
  5. Can you tell me about the last time that problem happened?
  6. Why is it a problem for you?
  7. How did you find your current solution?
  8. What’s not ideal about this solution?
  9. What is the biggest challenge you’re facing as a business owner with respect to analytics?
  10. I’m actually exploring a solution in this space. Can I contact you if I find one?
  11. If I wanted to put a solution to this problem in place, who else would I need to get buy in from?
  12. I’m trying to get a broad understanding of this problem from a wide range of perspectives. Do you know 1-2 other people in your organization who are also struggling with tracking product usage/analytics?

MVP:

The next items to consider are MVP feature set. I like to air on the side of underdeveloped MVPs and add what resistance we get down the road, if needed. Some people like to build very polished feature sets. Just personal preference.

Feature Set:

For this MVP I would think a few things will matter.

  • Install JS snippet - we need to be able to collect data easily
  • Validate the JS is only running on websites that we allow
    • i.e. Valid customers accounts, prevent from running if URL is not registered and/or payment was not collected
  • Tracking the analytics - log in, device, location, what pages each user went to, what features that user used, aggregate users across accounts, % of new features used
  • Add team members - CEO signs up for account. Would be really great to be able to add 2-3 team members to view the data as well. Email would probably be easiest to do this. This is slightly outside our core ethos because we are targeting small teams but I want it in so that adoption has a better chance of success. The last thing we want is to win an account, have a champion who gets a new role, and our product be extinct in the org.
  • Save data to integrate with other products down road as needed

Features To Add:

Prediction - I have not decided to put this feature in the MVP yet but the idea would be to predict where a user is likely to go next, and preload the page such that the instant they click there is no wait time. Not entirely sure it fits product ethos though. The pros of the feature being it helps end users find more value in the software they’re using. The cons being it slightly sways outside of our core focus of providing lightweight, easy access product analytics.

NPS - This would be nice to have, but there are a lot of products that do this, and our core insight is to be incredibly easy and lightweight. Every feature we think about adding needs to be weighed against that core ethos.

In App Chat - This once again would be cool. But, there are a lot of products that do this very well, and our focus is on product analytics. Not on chatting with our users. This would be nice, but at what cost to the core development? Not worth doing now.

Integrations - These most likely will be needed but at a later date. Will revisit once 10 customers are on-boarded.

Prototyping:

I will be using InVisionApp to build out some basic prototypes. A few core questions I have:

  • Could we get all data from google analytics, and not need to install anything then?
  • Could we find a google analytics code on potential customers website, and show them some examples of what their data might look like?
  • What could we do to avoid customers actually having to install a JS snippet?

Will add links to project later on.

Technical Details:

I recently did very poorly on communicating an architecture design, and why I would choose to build a product that way. I am going to use the next section of this to articulate, in a thoughtful way, how this product would be set up. This will help me improve upon some weaknesses I have and become better!

Platform Decisions:

I always use AWS. I like to have the flexibility afforded to me through their platform. I also have the most experience with it. Anytime I’ve tried to use Heroku (or similar services) I get towards the very end and then can’t set something up how I like. With AWS I trade some headaches getting configured (learning to use Terraform for this) in exchange for flexibility.

I could use the same old same old set up. Doing everything manually in AWS but this project is about personal growth and learning (and forcing myself) to deploy using Terraform will be super helpful. I referenced, studied and learned from this resource. I would suggest anyone interested in AWS do the same. It is incredible.

Database Design:

I have not yet made all database decisions but it looks like we’re going to have 2 tables (db yet to be determined):

This set up will let us easily:

  • Add new users
  • Segment our users by role
  • Segment our users by company
  • Segment our users by team
  • Segment our users by plan
  • Segment our users by admin
  • Display data nicely formatted on a team wide level (all product managers)
  • Display a stream of data
  • Log usage rates for products:
    • what features each account uses the most
    • what features each account is not using (to remind them before they churn)
    • what roles use different features
    • what pages new customers use the most, etc
  • Easily add extra team members and show them the right data
  • Save data so customers can integrate other products down the road

Our tables are below:

Users

UUID Email Password First Name Last Name Role Company Team_id Plan Admin
01 user1@gmail.com *** Kameron Kales Product Google aeiehad001234 Professional Yes
02 user2@gmail.com *** John Doe Sales Google aeiehad001234 Professional No

Data

(This is the one I am not the most sure about)

Team_id User_id Event
aeiehad001234 customer@gmail.com click event
aeiehad001234 customer@gmail.com viewed /dashboard
aeiehad001234 customer@gmail.com searched /view

I previously listed out a separate 3rd table for teams but that was unnecessary.

I have spent some time thinking and I don’t think the team_id field will be necessary. In this case it was acting almost like an API key, where we would unify the data. I believe we can use URL instead. And only allow the JS to run on validated websites. I will come back and add more information on this once I get further along.

I grabbed an example architecture that I would like to model from the system design link listed above.

Architecture

This is set up to scale for a large number of users. Overkill for an MVP but we’re focused on learning here.

Technical Architecture:

Now I will walk through some of the systems being used, how they relate and how everything will hopefully work.

The client is dependent on the users device. This can be things like different versions of Android, Iphone, or IOS devices + browsers like Chrome, Firefox, Brave, etc.

The DNS portion will be handled by Route53 on AWS. I use Route53 because of how easy and reliable it is.

The CDN portion will be handled by CloudFront. I have not used this specifically before so I am eager to learn how to set it up.

The Load Balancer portion will be handled by Elastic Load Balancers. I have done this seemingly hundreds of times and it is fairly straight forward. Although, this will be the first managing with Terraform.

Web:

I have decided we’re going to do the UI in ruby on rails w/ VueJS. I have never worked with either of these so this will be a learning experience.

I have changed this. I will be using NodeJS w VueJS for the UI. I have some code I can reuse and will most likely write something else in Ruby. My computer was also being absurd with getting Rails to run so I moved on. This layer will be deployed in a docker container.

This repo looks promising for our starter code.

Data Stream:

Why use Go for the stream? Honestly, I’ve wanted to do a project with it for awhile. Go, Python and Node are the 3 fastest cold start runtimes on Lambda. I’ve used Node and Python extensively. IF I was shipping this on a fast timeline I would probably write everything in Python and move on. I believe we will need something like Kafka to store.

I found this article comparing Kafka vs Kinesis for our streaming layer. The article is a high level summary which links to the white-paper. I’d suggest reading both.

JS Widget:

The JS widget will be informed via this site. I have not previously built one so this will be a useful resource in doing so. I am going to write the above in vanilla JS to keep the widget as small as possible. This should ensure fast load times and minimal resources added because of our product.

JS Widget Methods:

I have previously strayed in scope through development. In order to fight that I am going to define exactly what the widget will log, and what functions it will use to do so.

All methods will be available via Grand.

  • Grand.LogIn()
  • Grand.SignUp()
  • Grand.PageView()
  • Grand.TimeOnPage()
  • Grand.FeaturesUsed()
  • Grand.Contacted()
  • Grand.Purchase()
  • Grand.Trial()

Database Implementation:

Database info will be added once I make a decision.

Deployment:

We will be deploying all of this via Terraform.

Product Development:

There are a few places I could start with the actual product. Before writing code the above (interviews, notes) are going to take place. From that point I might update the MVP feature set a tad, and then push an update to this post.

You can use this Trello board to follow along.

I am going to use TailwindCSS to design our UI.

Product Priorities:

Once that is set, I believe I am going to tackle the JS widget + Lambda function first. I want to ensure this is 24/7 reliable and hardened as it will be the most important part of this proposed product.

After the JS widget I will be finishing up the UI. This won’t take long as I am pretty competent in node.

Once that is set, I will write the Python service to standardize and deal with the data. I imagine we will get a wide variety of data coming in, and making sense out of that (for what matters) will be important.

I recently got the RefactoringUI book and will be implementing the design pointers they discuss throughout this product development cycle. More info to come once I get that far!

P.S. This guide is not done. There may be more details added, changes made and/or spelling errors. Deal with it!