At Altar.io we’ve built dozens of products over the years, working with entrepreneurs from all over the world. Based on that experience, it’s absolutely clear to us that one of the key elements of success is taking the time to reason with your product. We believe this so much we encourage every entrepreneur that works with us to start with a 5/7-day immersive process to align the product reasoning with the business goals, before building anything. We call it . Product Scope Recently, I had the chance to sit with founder, advisor & product expert Joe Procopio and talk about this exact topic: the importance of product when building an MVP. “You can do everything else right but if the product isn’t right, you’re doomed.”, he told me. “You can recover from every other part of the MVP process failing. You can’t recover from a misfire on the product.” Joe knows a thing or two about building MVPs, after all, it’s what he’s spent the last 20 years doing. As our conversation progressed, Joe shared his insights on not just building an MVP but launching it and evaluating the results. Let’s jump straight into it. About Joe Procopio Q: How many products have you built in your entrepreneurial career? Dozens. Mostly software-based products and SaaS. I’ve done some hardware and some retail, but mostly data-driven software systems and apps. A: Q: And how many did you help build by providing advice/mentoring to other entrepreneurs? This would again be in the dozens, but I don’t take credit for those products or helping build those products: A: “Advice is neither idea nor execution.” Q: On social media, you describe yourself as a multi-exit, multi-failure entrepreneur. From a product standpoint, what worked and what didn’t? I can say in each case where it didn’t work, it was execution-related. A: I’ve never been part of a startup that failed because the idea was shitty. Some were heartbreaking – like we failed because we simply ran out of money before we got the right amount of traction. Most of them, however, were just me and/or my team not knowing enough. Or not having the right experience. Sometimes it was not having the right people to turn to or not getting the right advice. That’s, partly, why I spend so much time trying to make sure more entrepreneurs get the right advice. On the success side, we built what the customer wanted and then we scaled our operations to be able to do that over and over again with fewer and fewer resources. It’s not a complicated thing — I mean the execution of it is complicated – but the idea is simple: “Build what customers want and then scale.” The Importance of a Startup’s Product Q: What are the core elements to focus on as you build an MVP? : I’ve written dozens of posts getting to the but ultimately: A heart of that question “It’s about providing the most value with the least friction.” The first step is to define the value proposition and stick to it. When building an MVP you must: Test the core functionality of your product Test the full delivery system of your product Prove the market viability of the idea on which your startup is founded. Of course, this doesn’t guarantee your MVP will be successful. It is imperative, however, that you test the above hypotheses – any feature that doesn’t do that can wait. Next, you have to avoid sabotaging your MVP. There are common mistakes you can avoid that will perpetuate that sabotage: The MVP isn’t an MVP at all. Instead, it’s somewhere between an overproduced demo and a really shitty version of the final product. Your MVP’s core functionality doesn’t work (or works so poorly it can’t be accurately assessed) The discovery, delivery and support processes fail the MVP, creating so much noise from bad customer UX that the handling of the MVP that all the data about your product becomes moot. Your MVP is successful but you underdeliver on the final product. It seems your MVP is successful, but the results are a lot of false positives around functionality that won’t scale and grow into something valuable. The next step is to build your MVP from the sky down, not the ground up. This is how the birth of a new startup product almost always works: You have the idea, you find the talent, you draw up the roadmap. So now what do you build first? Never start with a blank slate and go directly to MVP. It’s a classic path to overbuilding – which is a short road to failure. “Instead of starting with a blank page, you need to write the MVP story from the ending backwards.” Any good author will tell you that they write the end of the book first, and then they’ll work backwards to the beginning. I talk about Three Stories a lot. Story A is what you’re doing today, Story B is what you’re trying to grow into, and Story C is the home-run billion-dollar company. Write Story C first and work backwards to Story A. That’s how you build an MVP. Now, you’re going to get some of the future details wrong, but it’s much easier to go back and rewrite Story B and Story C using what you’re learning from Story A. On the other hand, it’s almost impossible to start by writing Story A and then hoping and praying that your Story A results in a compelling Story B and Story C. Lastly, you need to build your MVP around the core – So what’s the core? It’s those features that show value immediately. The core has to get the customer to a quick understanding of why they need your startup product. And it has to do this flawlessly. Remember: “Your MVP won’t work if your customers can’t see any value.” Which leads me back to the beginning of this answer – always think about value. When I write a post, I’m not just thinking about the moment, I’m thinking about value. Am I providing value to you, as a reader, and not just showing off my experience? Am I providing value to every other reader like you, generating insights that apply universally? Am I setting you up so that you’ll want to read the next thing I write? Applying those types of questions to your product will help you find the core of your MVP — immediate value. When your customers are done using your MVP, you need them to want to use it again, exactly as it is. That’s the core. Everything else — and all the features you have planned for later — should only serve to enhance that value, not create it. “When your customers are done using your MVP, you need them to want to use it again, exactly as it is.” Q: Given that you’re an expert on the topic, why is it important for a startup to focus on product as you build an MVP? Because you can do everything else right and if the product isn’t right, you’re doomed. A: If the product doesn’t provide value, you’ll fail. If the product can’t scale, you’ll fail. If the product isn’t unique, you’ll fail. “You can recover from every other part of the MVP process failing. You can’t recover from a misfire on the product.” You have to dig deep to its . core Q: The approach to building an MVP is widely written about online; do you feel that a startup’s product is also being given the importance it deserves? The best ideas, unproductized, are great lab experiments. A: The best tech, unproductized, makes a great patent to put in a drawer somewhere. There’s nothing wrong with either of those things. But when you build a business on an idea or tech, you need to package that tech in a way it can be transacted. That gets missed a lot. Productization is the difference between something being really cool and something being a must-have. Q: Why does this problem of “unproductized” ideas seem to be even more visible in the corporate world? The corporate world is just now starting to grasp the importance of product science and product engineering. A: That seems odd because it’s the corporate world, right? But for decades, productization in the corporate world was a part of marketing or project management. We’re only now starting to see the science and engineering aspects emerge in some of the startups that have grown to corporate size over the last five or ten years, they treat product very differently. Making the Right Decisions Early On Q: The importance of a lean approach is clear as you build an MVP, yet most projects end up with a Most Beautiful Product (MBP) instead of an MVP. Why and how can it be solved? An MVP should be ugly, but only to the company, not to the customer. A: I’m not 100% sold on lean as an approach so much as it is a philosophy. Just being lean doesn’t imply you’re making the right decisions, it just means you’re moving fast and able to react quickly. If you’re reacting to anyone who isn’t the customer, you’re not building an MVP, you’re building an MBP. Q: How important is it to build an MVP for the future? I just wrote a about this: A: post You need to plan for scale right out of the gate, immediately, but you don’t need to build scale in right away. The growth stage is about building scalability to plan. You should always be thinking a couple of steps ahead when you’re building an MVP. However, if you build too far out, you’ll wind up building in technical debt or building for use cases that aren’t your primary use case. You’ll wind up wasting time and money. The Framework To Building An MVP Q: Do you have a specific framework you usually recommend when building an MVP? I’m not a huge believer in frameworks for entrepreneurial ventures, although I don’t disparage them. A: I like the idea, but if there was a framework that was 100% successful then we wouldn’t need the entrepreneur. I believe in flexibility and creativity. That said, there are common guidelines that you can wrap into a framework to package working strategies into a usable model. I’ve toyed with building something like that and I think it can be done, but you have to erase a lot of common misconceptions about how startup and MVP should work. Related: 3 Steps to Build a Successful Minimum Viable Product (MVP) Preparing the Launch Q: After you build an MVP, how can you make sure it’s ready to launch? There are a series of things to do before you even launch your MVP, essentially you need to: A: 1. Make sure everyone is aware of the MVP’s goals: To put it bluntly, our MVP is trying to determine whether or not our product deserves to exist. We do this for two reasons. 1) To get to market as quickly as possible and 2) To reduce the noise those additional features will add to our test results.” 2. Define success and failure – and what to do if our MVP neither succeeds nor fails: Success means X many of our customers use the MVP this often, in these ways, for this long, and are thus engaged with it. Failure means the opposite. We’ll also need a plan for what to do next when our MVP neither succeeds nor fails. What did we miss? What do we tweak? Do we do another MVP? How much time do we spend manually polling and surveying customers? 3. Test the shit out of it: Before the first customer sees our MVP, we should go through every use case, every edge case, and every crazy thing we think our customers will do, out in the real world. We shouldn’t just make sure the MVP doesn’t break. It should break, and we need to figure out the likelihood of that happening and what we’ll do about it.” Launching the MVP Q: How to make sure that MVP delivery, execution, and support are all on point? There’s a lot to unpack here. A: The thrust here is to make sure you can triage everything because that’s the most critical part for the customer. Delivery has about a thousand different answers depending on what you’re selling and to whom. You can say the same thing about execution as well. “The key to all of it is to make sure you have communication in place. At every touchpoint.” Your team, suppliers and vendors should all know where and how to communicate. Your customers need to be able to get to you quickly and efficiently. And all communication should be documented. Q: How can you make sure everything is measured and that the decisive changes happen? So this goes back to making sure you can scale from the beginning. A: You need to be able to scale the company too. You should be tracking all the interaction from customers in, between internal teams, with suppliers and vendors, and company out to the customer. The more real-time and more granular these measurements, the easier it’s going to be to make decisions on changes. And for : those changes to take effect smoothly “Measure everything twice, and cut and add with authority.” It doesn’t have to be elaborate. Spreadsheets can probably work at first. But you will be happy in the not-too-distant-future when you can go back to data and analyze where things went wrong or right. Evaluating the MVP Q: When can an MVP be considered successful (product-wise)? Can an MVP be successful even if it fails? People assume that if an MVP fails it is still a success, because of what you learn. In my book, that’s false, no matter how much data or answers it gives you. A: “An MVP isn’t an experiment of an idea, it’s an experiment of an approach. An MVP is only successful if it evolves into a successful launch version.” If you have to pause or go back to the drawing board and change a lot of things, that product was not viable. Many times the MVP lands in that dreaded in-between result. And it’s probably the most popular result, right? Now, this is a fine result, but only if it provides a benchmark with some data that you can use to get to viability. In an ideal world, the run of this MVP doesn’t end with an indifferent result. With flexibility and creativity, you make customer-prescribed enhancements and changes on the fly. An MVP run only ends in either total failure or success like I mentioned above. Either way, you’re out of the MVP process at that point. Thank you, Joe… I’d like to thank Joe for taking the time to bring his insights on building an MVP for your startup. For more actionable tips and early-stage startup advice, check our . blog Thanks for reading. This post was originally published at Altar.io.
