Overview

For the better part of the last 10 years, I’ve been working within a #Startup environment. In 2011 I co-founded an #EdTech startup that helped educators automatically grade multiple-choice tests with their phone cameras. In 2014 I joined #Catalyze as employee #10 to help break down the barriers to compliance in the cloud. In 2018 I was promoted to #[[Chief Product Officer]] at #Datica where I helped scale the #Product and #Engineering organizations while going through a merger.

Throughout my time as both an employee and founder, I learned a lot about building products — what works, what doesn’t work, when to do certain things, and how to deal with major failures (and successes). I’ve made too many mistakes to keep track of, but in those mistakes were critical lessons. Often lessons that can only be learned through struggle.

Who Should Read This

My goal with this article is to save future #Founders and #[[Product Managers]] from having to experience these failures first hand. The following is an aggregation of 7+ years of building for #SaaS #Startups.

This advice can apply universally to startups large and small. However, these principles are mostly aimed at helping tech startups scale from $0 to $10m in #Revenue.

Consider this list a work in progress that will grow over time. If you have any product tips for startups, I’d like to hear what they are. I can be reached via email or twitter.

Principles

Always test the market

Testing your ideas with prospects and users should be something you’re continuously engaged in throughout the #[[Product Lifecycle]].

Testing ideas doesn’t have to be complicated. You can test ideas, thoughts, and improvements all just by talking with people. Your goal is to collect #[[Qualitative Data]] through customer conversations and prospective interviews. Some of the best #Features I’ve built have come through random customer conversations.

How many of these conversations you need in order to #Validate an idea is entirely dependent on the size of your business. I typically aim to have 10 conversations about an idea before I consider it validated or not. This gives me a set of foundational #Data to share with the rest of my #Team, and tells me what’s important about a feature and what isn’t; all before I’ve designed a single #Mockup or written a line of #Code.

Collect data early and often

One of the bigger mistakes I’ve made in the past has been to push quantitative data collection off to a later release, instead of making it a requirement of the product launch. Even a manual data collection process (ex: querying a database for the data you want) isn’t good enough.

You need to have an automated metrics gathering tool in place at launch. This has been made exponentially easier over the years by new #SaaS products. If you’re looking for something free, I’ve had success with Metabase.

Simplify your roadmaps

Another mistake that I made early in my product career was building complicated roadmaps. I used to obsess over these massive, large scale roadmaps with hundreds of features that would span 12, 24, and 48 months into the future. Unfortunately, I was often the only person that used these roadmaps. Partly because I was bad at evangelizing the roadmap, but also partly because it was just too complicated and drifted further from the truth every day.

Having an easy to reference roadmap is critical to ensuring the entire company knows what you’re building. Additionally, companies searching for product-market fit should only be thinking about the next four weeks. Having a roadmap that looks out even six months is bound to fail.

Live by your critical metric

Your critical metric is the single most important piece of data you can collect and track against. There is no playbook on finding that metric. You have to collect as much data as you can and build a hypothesis on which needle in that proverbial haystack matters the most.

Everyone is in sales

As a product manager, being on a sales call is one of the easiest hacks you can use. It gives you an immediate reaction to the offering in the market. It tells you how well your sales team understand the product (you have to listen to them talk about it). It tells you what features, packages, pricing is resonating with users. It even allows you to do some qualitative research. If you’re in a B2B organization then you should have no problem jumping on 3-5 phone calls per week.

Simplify problems

Products hinge on problems existing. It’s important to state the problem your users and customers are facing simply. This helps sales, marketing, executives. etc. understand complex issues. In the B2B space, specifically in markets like developer tools, you’re going to work with non-engineers all of the time. So while your users might be technical, not every stakeholder will be. This is where techniques like Jobs To Be Done can come in handy. It forces the product manager to think about the atomic level problem that exists. It removes all layers of complexity. There’s no market, there’s no user profile or demographic. There are problems and humans. That’s it.

Hire amazing employees

Startups often make the mistake of bringing on a product manager from a large corporation to own a product too early. While experienced product managers can be worth their weight in gold, you need to hire them at the right time. For early-stage startups, I often suggest promoting an engineer or designer that already has experience with your product and users before hiring an outside product manager.

Always own product

At first, this is typically a founder, most often the CEO or CTO. Disaster unfolds when product ownership (not necessarily management) is ambiguous. Product management is not complicated. You don’t need a VP of Product, or a Chief Product Officer on day one. What you do need is someone passionate about the problem you’re solving and the ability to listen and distill.

Focus on now

At the risk of choosing the wrong analogy, I often compare startups to raising a child. Newborns change at an incredibly rapid rate. Week 1 is drastically different from week 2 is drastically different from week 3 and so on. At some point though, things start to slow down, your children start to have engrained personalities, they change less frequently.

Startups function in the same way. In a pre-product, pre-revenue startup you’re constantly changing strategies, often within the same day. This is because you’re learning at a rapid rate. You should be taking in as much information about your users and the market as possible. At some point, you’ll figure out where the opportunity is, and you’ll start to even out. Understand that rapid change is normal, but it needs to be controlled. Focusing on what matters now helps to manage the chaos.

Part 2

That’s it for part 1. Part 2 will be released in the next few weeks. I have roughly 100 of these principles that I’d eventually like to publish, so there will definitely be a Part 3, and likely 4 and 5 (if not more). If you have any feedback or questions I always encourage reaching out to me via email or twitter.

One last thing. If you need help with remote work, product strategy, compliance or security then please contact me. I’m taking on 1-2 more clients. You can read more on my website here.