As any new startup or product team can tell you, it’s hard to start a new project and not just jump straight to coding features and tools.
Even though the MixFrame team only has a short timeline for building the product, we’ve spent a large amount of time on planning and setup. Sure, we’re coding like crazy; it just hasn’t been the primary focus in our first two weeks.
We’ve already talked about overcoming the uncertainty of starting development on MixFrame, but we also faced the uncertainty of where we’re heading. We knew that a healthy product roadmap for MixFrame was impossible unless we had the knowledge to adjust course intelligently throughout development. So we started building rapidly, without focusing just on getting the product out the door.
Focusing on Viability
As an organization, 352 talks a lot about minimum viable product (MVP), and not just for our clients. Our CEO Geoff has painful, first-hand experience with building a huge product without actually testing it with customers.
Many people wrongly think of MVP as simply the quickest way to introduce a new product to the market. At its heart, however, an MVP’s purpose is to teach you something about your product idea. Eventually, it’ll show you the path to create a product that users crave.
With MixFrame, we don’t want to build a lot of features – we want to build the right features. To reach that goal, we realized a little bit of early foundational work will pay dividends for the lifetime of the product. Mostly importantly, we realized that our product will live and die on data and healthy code.
Marketing played a huge role in winning our Hackathon, and our product growth team has been integral at every step of development. Every story includes measurement, and we’ve baked in lots of analytics and tracking hooks from the start. We’re creating a lean MVP, and this level of data will immediately let us identify which features people love and which are duds.
Focused on All Kinds of Growth
I’ve worked with a few startups and new products that failed to lay the proper groundwork for iteration. An MVP should obviously be a platform for growth, yet too often product teams only focus on feature growth – not customer growth or sales growth.
At some point, we know other 352 developers will step onto the project as we roll back onto client work, and we want to leave a product that’s ready to adapt to customer needs and development best practices. We’ve been steadily unit testing every new line of code to avoid bugs and build a small safety net for future developers. This sets the table for future growth, and it forced us to structure our code in a better, cleaner manner.
We’ve also obsessively built for the right customer. Even though we’re building a product for front-end devs like ourselves, we didn’t want to fall into the trap of building a product only we’d love. Our UX strategist interviewed more than a dozen front-end leaders for feedback and guidance, and we did a company-wide survey to ensure we were using best practices for future development.
It may seem odd to use our short development window to focus on measurement and product health, rather than solely on features. Yet, we’re building rapidly toward a long-term vision. Check back next week to see more progress.