How to Get Started with Product-Led Startup Metrics
In its early stages, a startup has incredible flexibility to build on a vision. You’re moving fast to fulfill your vision and the product is starting to show the glimmer of promise of what it can be. For a startup built around product led growth, watching users sign up and start to use your product can be very exciting.
But there quickly comes a point where vision meets reality and the team needs to understand what’s working and what’s not to better prioritize the scant resources available.
When we first started building Docket, we were sure we knew what the “aha” moment for our customers would be. We had a vision and made logical assumptions about what users would do first in our product based on our knowledge of how to run productive meetings.
We were wrong.
Turns out that users were finding our product in the middle of what we assumed the user journey would be—and our product wasn’t taking that into account. Luckily we built the product from the very beginning with a measurement mindset, so we quickly understood our mistake.
Measure early, measure often
Build a measurement mindset into your company culture and your product from the start. It’s much easier to do this in the early days and much harder to retrofit in at a later time.
It takes lots of practice to create a product culture that intrinsically knows everything you build should be measured and every feature should be rolled out as a test. It impacts everything about the product lifecycle, like:
- How to prioritize features based on goals set
- How to architect and build the product
- What tool sets are used
- How features are deployed and monitored
When Docket first launched, we’d already instrumented the product to gather every bit of user behavioral data that we could track. As the data started rolling in, we sat down as a team to identify the metrics we were most interested in and immediately captured a baseline for those.
In general, it’s better to track more data than less. You may not identify the right “key metrics” in the beginning, and having data for all metrics already being captured makes it easy to course-correct along the way.
Now we start all of our product roadmap discussions with a definition of the success metrics for each feature. We identify what metrics each feature is intended to improve and set goals for each metric.
In the beginning the goals were just guesses, but we’ve learned how much impact we can realistically expect from our advancements. Don’t be as concerned about getting goals right in the beginning. Instead, stay focused on the importance of building the habit into your process and team.
So why are metrics important for your early startup?
- To know what to build proactively—when data strongly suggests a need that should be filled for your users. Our product is capable of supporting any and all companies and industries but our data and user feedback pointed us towards product market fit so we could invest our time towards building something really good instead of building a little of everything just okay.
- To know how to fix something reactively—when data shows an issue that should be addressed to relieve churn or other usage impacts. The data we track for our user engagement has made it very clear on where we should focus our attention from specific churn points to feature enhancements.
- To tell your investors a story—proof your vision is working and why investment in your company is smart. When we established our initial metrics, we shared them with our board to gain agreement on our strategy. This is especially important in the early days of a PLG company when revenue is lagging in your growth metrics.
Which metrics are important?
Users in your product are a current revenue opportunity and a flywheel to grow your business. Their use of the product, or lack of, is information you can use to steer the business in the right direction.
While it might feel overwhelming to choose a set of metrics from all of the possible actions a user can take, it’s best to start with some basic yet critical stats that will give you a sense of direction. The goal is to start! Your team will quickly understand what additional data they should measure once they start tracking the base metrics.
The need for data quickly reveals itself when you and your team start asking yourselves questions about the behavior of those using the product. If a question can’t be easily answered, it’s time to define and establish metrics that can be tracked and measured to provide immediate actionable feedback to your team.
What metrics are important for your startup?
- Acquisition. Starting from your website, the door to your product, track impressions, clicks, visitors, sign-up progression and users.
- Activation. Once someone transitions from your website to your product, track their movement through the product to find their “aha” moment (the moment they feel the value of the product) and the time it takes to get there. We use tools like Segment and MixPanel for event data and analytics as well as custom-built charts, graphs and alerts to keep the team informed realtime of the customer journey.
- Revenue. After the user completes their introduction to your product, track their road to conversion or expansion into the additional offerings the product optionally provides.
- Retention. Follow the user journey of existing activity to understand how long someone is retained in the product and what actions lead to greater retention.
- Referral. Track the various ways people invite new users into the product. For example, Docket enables people to send out professional agendas and recaps to other meeting guests. Many of the recipients of these notifications sign up for Docket, either to collaborate with the sender or to check it out for their own personal use. Docket also provides the ability to create your own team which triggers notifications to invitees to sign up as well. We track each of these as a separate referral type so we can understand which one drives a greater adoption of the product.
How much data is needed?
The more meaningful data you can collect from the beginning, the more data you have to make better decisions. Understand that collecting data is critical but making sense of it will take some effort among you and your team.
It’s also important to balance the type of data you need. For example, security and privacy is a critical consideration when it comes to collecting user data. Collect only what you need to make the product better for the user—and do not do anything that risks breaking people’s trust. Always put your user first when it comes to data.
Don’t be hard on yourself when you first establish the means to collect this data. The truth is, you probably won’t hit on the right things to measure right off the bat. What is important is that you establish some metrics you want to track, set the direction for your team, enable tracking and watch the data as it comes in.
How much data do you need?
- Reach statistical significance. You want enough data to clearly define the result. While the number of users will be small in the beginning, if you have 100 users and only receive affirmation from a user test from three of them without understanding the behavior or needs of the rest, you’ll likely make a poor decision.
- Discuss hypotheses. Work with your team to discuss the hypothesis around product enhancements and set a goal for what you hope the change will achieve such as % increase in activation or revenue. It’s a guess at first, but once you start setting goals and experiencing results, these guesses become more realistic over time.
- Test incrementally. Gradually build towards the goal so that you can invest into a project and receive feedback from customers each step of the way. Make it possible through your product to release small, iterative pieces and try the changes with a small set of customers at a time so as to not disrupt everyone during the process.
- Watch the data for results. Build, release, watch your metrics and build again based on what the data is telling you. Or stop building and question what you are working on if it’s telling you that as well. This can be hard to do after having invested the teams time in building an enhancement. At Docket, we made an assumption early on about how our users would want to collaborate within the product and invested time and energy from the entire team architecting the solution. The data kept telling us otherwise, so we decided to refocus our attention on more impactful features and set the project aside to learn more. Spending a lot of time building something isn’t justification for forcing it into the product if it’s not helping you meet your goals. In the end you’ll only confuse and alienate your user base.
- Keep trying. Trial and error is the name of the game. An error is not a failure but rather a sign that tells you which direction to go.
What happens next?
Don’t let analysis paralysis slow you down. It’s more important to measure the state of the business versus spending a lot of time debating or over-analyzing. Be okay with guessing in the beginning and the data will point you in the right direction.
What should you continue to do with the metrics?
- Find product-market fit. While some product ideas may be extremely straightforward, many require testing and observation to find the right audience and product direction. Continue using the data to find where the product fits best and watch it take off.
- Reshape your story. As product-market fit becomes more obvious, use the data to reshape your story with investors and through your website and marketing initiatives.
- Follow the feedback. Make better decisions for your product by using the data you receive through the metrics you are tracking.
Remember that everything about your product is a learning experience and should continue to be no matter what stage you are in. Using metrics from the beginning of your startup journey will help you and your team have a greater connection to the purpose and mission of your product and create an amazing story you can share with greater confidence.
Improving processes, adding more documentation and holding a bunch of training sessions won’t scale a product-led engine—it’s org design that matters.