Don't Let Your Product Strategy Happen to You
Product development is an emotional process. And, in my experience, it’s very easy to get lost in this process. In my work as an entrepreneur, angel investor, and co-founder of several ventures, I have seen (and fallen victim to) the trap that a product can control you. The product has a way of taking over to such an extent that it becomes the boss of your life.
If you don’t ask the right questions, you can find your product happening to you rather than it being a vehicle that helps solve the problems you care so much about.
Are you starting out with just the seed of an idea? Or perhaps you have an MVP and want to get traction. You may even have a mature product and be concerned that it seems to be losing momentum.
In all of these cases — and every stage in between — asking some tough but essential questions will help you align your product vision, metrics, process, and results. The right questions give you a framework to build strategic products without falling victim to burnout.
Do you have a clear product vision? Every business book you read proclaims the importance of vision and mission. All of my products have a clear, concise vision statement that explains the mission of each new product.
Be careful: Because if you do not, you may fall into a trap. I’ve seen many entrepreneurs confuse their excitement for a problem or solution and leap to believe that the corresponding products will succeed in market.
We often are told that passion outweighs product/market fit. Jason Fried is famous for encouraging folks to “scratch their own itch” and to solve a problem that they understand intimately. Sure, you might get lucky with this method. But here’s the truth: Entrepreneurs are weird, and you can’t always trust your own judgement. You might end up building something that only you would buy.
Believe me, I’ve been there. Entrepreneurs can get so passionate about an idea that we end up giving into the rush of endorphins that comes from working on passion products. People say that love is blind. And I’ve learned the hard way that absolute love for your product can blind you to its likelihood of failure.
Always start your product development by defining a clear vision. This is a lot less painful to do upfront than later down the line. It also prevents you from chasing windmills and it serves as a canonical reference for your team to ensure that everyone is marching in step.
Are you avoiding important work? If you’re an engineer type, you likely dread making cold calls — so you don’t. If you’re the visionary entrepreneur type, the last thing you likely want to do is sit down and carefully craft experiments to validate your hypotheses before going all in. Who has time for that stuff? You have a brilliant new product to build! (Right?)
People are funny. We are very good at convincing ourselves that the stuff we don’t like doing is not necessary or important. This kind of thinking can be dangerous on a tight budget. You either waste money on unnecessary features or suffer from lack of traction because you believe that your brilliant new product will go viral based on its own merit.
Yes, some products spread like wildfire without a sales team or marketing campaign. And there’s a big reason why this small group of products is always in the press — they are the exception, not the rule.
The story of Slack, for example, is fascinating. It is also anything but normal, and will most likely not happen with your product. So, what’s an ambitious entrepreneur to do?
The first step is to confirm what needs to get done, from tasks to releases. Lay out exactly what you must accomplish and by which dates. Do not worry about who will achieve each task. (Delegation comes later.)
Next, figure out a way to get these essential tasks done. Worried about cheating the process and not following through on your plan? Find someone to hold you accountable each week. This process clarifies what you need to push your product forward. It also helps you find solutions once problems become more obvious.
Now that you’ve confirmed what needs to get done and when, it’s time to assign tasks across your product team. I use a personality assessment tool called DiSC for myself and everyone else on my product team. (Full disclosure: I’m a bit crazy about DiSC. Everyone on my team has taken the test, and most of my discussions about people revolve around the strengths and weaknesses revealed through their DiSC assessment results.)
You don’t have to be as nuts about DiSC as I am. But I find it liberating because the results can help you visualize who on your product team is best suited for each specific task. Experience has shown me that the thing you hate is often what someone else loves. And few things result in stronger work than people who perform their work with passion.
This method works no matter your role or the size of your team. If you’re a member of a product team, methodologies like Scrum and Kanban help facilitate this work since everything will be put on the table to tackle as a team. If you’re the boss, this is your chance to improve at delegation. And if you’re working solo, then you may need to assess your blind spots and bring consultants or even a co-founder into the mix.
Are you using vanity metrics? If you haven’t read The Lean Startup, Author Eric Ries drops a few bombshell ideas. His first big idea is to ask if your team shares the same definition of success. There are many books and articles you can find about which metrics are most important for SaaS products. When you choose yours, make sure that you’re not focusing on metrics that sound good but likely don’t mean a whole lot. Ries calls these “vanity metrics.”
For example, total user count isn’t very helpful because it doesn’t give you any sense of momentum. If you acquired 10,000 users in your first two weeks thanks to a boost from a TechCrunch article, you could go on making yourself feel good about your user count — even if you only have 10,100 users at the end of the year. And, of course, that number doesn’t say anything about who is actually using your product. The emails used to sign up could be spam accounts for all you know.
The other bombshell idea that is pretty near and dear to my heart centers around the role that iteration plays in finding the perfect product/market fit. You should constantly be coming up with hypotheses to test through modest development effort, and seeking informed feedback on the results of these efforts.
If you don’t iterate — and therefore don’t nail your product/market fit out of the gate — you could find yourself in product purgatory where you’re not a success, but you are seeing enough traction to limp along and keep the doors open.
This is a deadly position. It distracts you from what you should be doing — either pivoting in a direction with more potential or shuttering your product to build something new from scratch.
I can think of three products that I closed down once it became clear that they would not live up their initial potential. Without a clear measure of success and iterative experiments, I would perhaps still be pouring time and resources into those products. That decision would have cost me millions in opportunity costs and prevented me from being much happier with my current set of products.
Are you under-communicating? Have you ever seen the tire swing engineering comic? The one where it shows 20 ridiculous variations of a tire swing on a tree as understood by every person involved in the engineering process?
If you take one lesson from this blog post, I would like it to be this one: No one communicates as well as they think they do.
When a group of people walks away from a meeting, I assure you that everyone has a different idea of what was said and next steps — no matter how simple and straightforward the discussion. Cognitive biases, agendas, proficiencies, and weaknesses all create confusion when groups work together. The teams who do communicate effectively know that they need to invest energy upfront to minimize misunderstanding. Communication issues will always be somewhat present; the difference is that it does not have to be disruptive.
Let’s say you want to minimize confusion around features and product development. The best way to do this is for the team to clearly lay out features in the proper user story format with proper acceptance criteria. Your stories should match this format:
“As [user role or persona], I need [something] so that [business value that should be delivered]”.
When product teams are in a hurry, they often cheat and include stuff like, “Fix user registration flow.” By contrast, the process above forces your team members to explain the “why” (business value) as they consider each ask.
We take communication to an extreme at Project Ricochet. Every ticket must conform to the user story format. Doing so forces us to slow down and do it right the first time. It helps us to think more critically. Questions that come up during the acceptance criteria phase can be resolved much more quickly and easily by the product owner than the engineers when they are knee-deep in code.
Most people forget the context required for each feature — especially when that feature gets backlogged and revisited at a later point. The other problem is that the developer, who may or may not have been involved in initial discussions, is now tasked with “fixing” this backlogged feature out of context. They will do the best they can with what they know. But what comes back is often not what was expected. The end result? A never-ending reopened ticket — a demoralizing dance for everyone involved.
On that note, the second most impactful piece of communication that can come from user story creation is for the product owner to clearly lay out their acceptance criteria. What exactly do you want this feature to achieve? Small teams that are in a hurry often skip this and assume that the developer will just “get it.” After all, it’s so simple! I have been guilty of this more often that I’d like to admit. But my team started nailing features on the first pass more consistently when I stopped assuming and started communicating.
There’s no way around it: Building products is tough work. But if you focus on vision, effective delegation, a clear definition of success, and communication, you can ensure that your product will not happen to you.
I think most of us want to do great work. The problem is our tendency to get in our own way. As a product leader and investor, I see accidental evil everywhere — even in my own companies. That is why I believe it is essential to:
Have a clear product vision
Delegate the work
Use the right metrics
Communicate
I strive to minimize accidental evil whenever I can by empowering my team to name it when it’s happening, to share the same product vision, and to follow the steps I outlined in this post. It’s what helps us to stay on track.
This is a guest post by Casey Cobb. If you are looking to be a great product manager or owner, create brilliant strategy, and build visual product roadmaps — start a free trial of Aha!
Casey helps organizations thrive by keeping founders focused on delivering value. He is Partner and Senior Software Engineer at Project Ricochet — a web development and design agency specializing in Drupal, Meteor, and Open Source projects. Casey believes in testing assumptions early and often. He puts that theory into practice as a software engineer, inventor, angel investor, writer, and speaker. Check out his personal website or follow him on Twitter.
