Putting the Product back in the MVP

Welcome to the software delivery club. Every two weeks. I explore different aspects of the business of delivering software products. Talking with industry experts about subjects that are crucial to building and delivering amazing software. We discuss customer needs, how products change and how changes get delivered. We also talk about keeping on top of our technological and engineering challenges. We talk about tools, both theoretical and practical. The ones that we like to use to improve our software products. As well as tales from the front line, all about delivering and supporting production grade software. Thanks for joining me. My name is Richard Bown. This is episode 16. All about the often heard and rarely delivered minimal viable product. I wrote about this recently and it resonated with lots of my readers. So I wanted to dive into the subject a bit more. Much is made of the MVP, the minimal viable product. But so rarely is it executed in a meaningful and valuable way. When I wrote about it, I gave it a quick rundown as follows. Take an idea form it quickly and work closely with the developer. A designer and a marketer to realize it as soon as possible. All this sounds simple enough, but how hard this is, and reality all depend on your company circumstances and how fast you can move. If you're a small, independent company, a non-corporate then perhaps there are low barriers to entry. You have your platform. Your technology stack perhaps already decided, or you can pick up a new one and play around with it. You are free to experiment. This can be nice from some perspectives because your MVP then also becomes a playground for new ways of achieving things. However, this can also be to the detriment of the initial intention. Too many choices can mean you're confused as to what you want to accomplish. If you want to focus purely on the product and be able to deliver functionality quickly than being distracted by a new technology may take away some of your focus. Ask yourself if the new technology is an enabler of this MVP, or if you can accomplish it using technology with which you're already familiar and comfortable with. Using an MVP to road-test new tech is not always a smart move. You might have also come across some formalization of the prototype phase of a project. This was often taught in the pre-Agile, pre Lean model of the software development world. A prototype could be built quickly and cheaply. But it was only there as a proof of concept and it should then always be thrown away completely after you've done with it. This can work effectively. Especially as a mental model for keeping your prototype down to a reasonable size or amounts of effort. However, the key difference between a prototype and an MVP is that the MVP is actually meant to exist for the user to try out. It's intended as a product. Albeit a thin or incomplete one. In practice, the prototype often ended up as a sort of unintentional MVP anyway. Many prototypes became final products. And I guess this is why the MVP became quite popular. Because we all know as engineers, that the first thing you build will be the thing that persists The first thing that is popular and actually makes a difference to your user, will stay. And this will then mean the architecture of the thing you're building will be based on your prototype. Architecture can be a problematic word here. In this case for me, architecture just means big decisions that you're probably not going to undo later. Usually the big decisions we make as product designers or software engineers are around what technology we're going to implement. While we would like to be abstract in our thinking. That comes a point when the reality of the supporting technology has to come into our thoughts. So technology choice is important because it's going to stick with you if your MVP works. However learning a new technology may be best suited to re-engineering or re-factoring exercise. Or if you're clever with your architecture, maybe you won't have to worry about this. You can drop in a new tech as you see fit. There is a tension here between architecture and MVP. You can't run ahead and architect because you don't really know where you're going when you start. You want that freedom to express your perceived customer needs in whatever way you feel is best. To back up for a second, that's one extreme. When you're a startup or just starting out with a new project as a soloist and you have all the choice it's mainly shaped by your preference. But let's look at the other side of things where you already have some technology stacks defined either by you or for you. You may have to play by the rules and regulations of your company or your auditor or whatever you see is as a constraint or the man figure in your world. The one who's setting the rules or the rules of the game that you must play if you want to deliver your software product. In this case, according to the theory of constraints. You could propose your change to the most constraining part of your service. You could align the majority of your efforts to make sure that this is signed off before you even start work on your MVP. So how could this look? For example, imagine that you're a developer working in a bank and you have an idea for an application that will tell us exactly how much energy your computer is using at this moment in time. It's not really possible for us to know. But, let's just say you can estimate how much energy is being used by your computer, by the software that is running on it. You think that this will be a great thing for the bank's customers. It could be given away to them to help them limit their energy use, to save them money and to show how much your bank is thinking about the environment. So you have a great idea and you'd like to get approval for an MVP that you could deploy on the banks devices, to other members of staff and get an idea how it would work and gather some feedback. You've already cleverly developed this piece of software so they can work on every single device in your organization. From mobiles to laptops, to data center, to cloud instances. And even switches and IOT devices. It's lightweight, deployable anywhere. Your constraint here is that for each of these platforms, there will be rules. There'll be separate approval processes and different people involved in their approval. For example, the mobile device organization will sit in a completely different reporting and approval line to the data center. If you want to do this on a cloud instance, you'll need to find all of the various groups that are using them. So you've got a potentially great solution but perhaps your reach is too big in this first instance. Are you trying to accomplish too much? If we get back to the original mission to give this to our customers. Perhaps we can just focus on one device type to begin with, say mobile. And then perhaps we can narrow it down to just Android. If that's easier. And then perhaps we can identify a single group of Android users in a friendly part of the company. By narrowing our proposal for our MVP, we stand a greater chance of getting it approved and rolled out in order to gather feedback. Also, we reduce the amount of administration we need to do. If you have rules in the workplace about infrastructure, about coding standards, about security baselining then you're always going to struggle to make a product as minimal as you'd like. But perhaps your environment has thought about that and you can use something like a paved road, a landing zone for your application. Then perhaps you're need to understand all of the other parts is reduced. Some of the work in your MVP becomes an investigation. How you can best accomplish what is closest to your original mission without getting too distracted by these pieces. This same discipline, thinking about the constraints we have in our systems as a corporate, is a great thought experiment we can also do if we have fewer constraints on what we can do in a startup world. The reasoning behind the processes that build up around change control are all there for sensible reasons. They exist because we as an organization of any size, are scared of making mistakes with customer data, with new functionality and features. And we want to have a world where we deploy changes in a controlled and useful manner, which is above all safe to us and to our users. Therefore our MVP in either case here has to stick to rules written or unwritten about how our product will behave and also what it allows us and the users to do. Yes, ideally these days we have all the freedom in tech, in functional and design choice. But when it comes down to it, often group dynamics, supportability, accountability, audit, compliance, and other factors. May limit our choices in a practical way. Whatever of path is open to you, your MVP won't deliver unless it has users. So along with speed of delivery, you must ensure that you make some noise. Create a landing page for your app. Describe what it's going to do. Get some users signed up to a mailing list. This applies, whether you're internal or external customer facing product. The point of an MVP is to prove there is a need for something. To realize it, you need technology, product design and product marketing. The commitment of users wanting to use your MVP will drive you forward. Don't leave the marketing to last or as an afterthought. And this applies not just to startups or individuals, but also to the scale-up or corporate world. Your hard work should be represented to something that is of use to people in whatever form that takes. When we write a library or a module that can be reused, provide examples. Make it easy to integrate. Put it on platforms where others congregate and are likely to benefit. Because there's nothing worse than a failure. Or launch into the sound of nothing. And again, the engagement of your audience is the point of your piece of software. Your compliance journey is also engaging an audience. It's a restricted audience with a certain worldview but that doesn't necessarily limit them to having opinions solely on whether your MVP is compliant or not Use that as an opportunity to also gather more feedback. Like any creation, releasing an MVP to the world can be a scary thing. So engaging with your audience before you release it, is never going to be a bad idea. To set expectation. To hopefully not oversell it in the first place, but to have an audience which will use it and love it and give you feedback. I'd love to hear your stories about MVPs and how you've got them into the world and how, when they arrived it differed from your expectations. Usually we get very different results to what we expect or anticipate. And that's the whole point. I hope you've enjoyed this week's episode. Please check out my newsletter where I explore the subject of software product delivery every day. You can sign up by going to software delivery.club. And you can also reach me on Twitter. At @richardwbown that's R I C H A R D W B O W N or on LinkedIn or via the website. Until next time, keep coding, keep dreaming and keep thinking product. Goodbye.