The startup world can be fast, exciting, and fun. You often get to build entirely new solutions that no one has thought of before, acting in a creative capacity that few other roles can compare to. So many professionals jump at the chance to build something new and this excitement makes it easy to focus on delivering the coolest features possible, forgetting to devote time to critical decisions that will impact future success.
At Mark Two, we work with companies to build success into their products and processes from day one. To avoid the build trap (to give a nod to Melissa Perri), you need to be disciplined about decisions you make at the birth of your product and we’ll explore a few ways to do that here.
Be able to ship and ship fast
For the non-technical, this is how your development team gets the features they’ve completed to the hands of users. For the technically minded out there, this is your build process. This might mean deploying an app to the app store, shipping an update to a product users download, deploying a new version of a website, and many more things.
These days you need to have some CI/CD pipeline that takes working code to the hands of your users within minutes. Notice the term “working code,” because a good build process also prevents bad code from being deployed and breaking your app.
You need this from the earliest iterations of your product. Build a delivery process that allows you to effortlessly and painlessly ship updates. There are so many reasons you need to be able to ship fast – in case they aren’t obvious, here are a few:
-
You need to iterate and iterate a LOT towards product market fit
-
You are going to break things, and you need to be able to fix them fast
-
The faster you ship, the faster you learn
-
Every moment you spend building something is time you aren’t spending adding value to your product
Know when you’ve broken something
Speaking of breaking things. Since we’ve agreed that will happen a lot, your team will need to be able to figure it out quickly. MVP development is a great time to refine response times. Getting the time-to-fix as low as possible early in your process will pay dividends later when you have paying customers irked at busted software. Practically, this means that you need to be able to track:
-
When errors occur in the application across your environments
-
Who is experiencing errors and the circumstances around the errors
If you have someone using your software experiencing an error, and one of your developers can’t find a trace of that error within minutes, you need to improve your tooling. Best case scenario is your developers reaching out to you before you’ve had a chance to reach out to them, because they’re tracking errors and want to stay on top of them.
Know how you’ll track success
If you have a product team worth their salt, they’re not going to want to launch features without knowing what metrics to track to measure impact. Don’t over-engineer complex tracking solutions at this stage but DO ensure that you understand how you’ll track different metrics throughout the lifecycle of your product.
-
What data will you need to examine to understand product trends
-
How you will measure the effectiveness of product releases
-
How you track your north star metric
In addition, you need to be able to track the overall health of your application. If you’re a website, track your apdex or an equivalent metric and have a goal your team is working towards. These are table stakes for successful applications, so start by giving these the recognition they deserve.
Build this as you go, not before you go
Don’t misunderstand the above to mean that you don’t start building your product until you have the above figured out. Instead, build it with your product, and make it something you consistently iterate on the same way you would any other feature. These are all areas of your product that will grow and evolve over time, and starting with them up front will help you ensure you keep these concepts front-of-mind.
