Focus on making a lovable product, not ‘minimum’ component.
I always get nervous when students say they’re focusing on building the ‘minimum viable product’ (MVP). My assumption is that they are not talking about the same concept that I have in mind. I always ask a few questions to confirm if we’re talking about the same thing. I ask them if they’ve discussed any of this with their client, and potential customers. If they are far enough along, then I also ask what their thin slice is at the moment.
Minimum viable products are prototypes. Prototypes should break. Do they break where you expect them to break? Or, will they surprise you and break in an unexpected manner. Second, an MVP is there to validate assumptions. Are the students doing both of these (testing the prototype, and validating assumptions), or just using the buzzword? Have they created a path to find the right features? Are they in a bubble and not talking to anyone, or are they getting out of the building, and talking to people about the idea?
All too often I find computing students think they know everything, but do not get out of the building to validate their assumptions. This is not how you build an MVP.
It’s all about shippable products
Ages ago, before he wrote about kanban, David J Anderson wrote about minimum marketable features as a way to strip a product back to the basics. With your MMF you could focus on developing this part in order to get it out the door and in people’s hands. This would help you learn about what you ‘got right’ and what you ‘got wrong’ so that you could improve the app, and grow your revenue.
It was part of his discussion on why software development should focus on getting code deployed. This boils down to the simple concept of ‘software as product’. Software that is not deployed is the same as stock sitting in a warehouse. When it sits in the team repo, then it can’t bring in money. Software only counts when deployed. Until then it is a growing cost. Your goal as a developer is to deploy your code, so that it can potentially bring in money.
I realise now that I should teach more students about the MMF concept and ensure that they understand MVP more clearly. Doing this would make it more understandable why you want code deployed sooner, and why it is important to be aware that your assumptions must be validated.
MMF also nicely aligns with story mapping to unearth the key components of the bare application. Each thin slice can then be developed and validated. If successful, it can be develop further. If not, then it can be pivoted to a new option.
The MMF approach lets the team focus on the application as a whole. MVP seems to be about ‘features’ and not the whole. Focusing on the whole app, or at least the basic parts that need to work together, makes it easier to develop and deploy a working application. From here it is easier to move forward, and keep the app deployed.
MVP is too narrow in my experience
Some of the misconceptions around the MVP seem to come from Henrik Kniberg’s poster, which I know that I’ve discussed with students repeatedly. It’s a great poster as you can see. I always found it hard to explain that we’re not perfecting wheels and then going from there component by component to the car. Instead, we should validate the assumption that a wheeled device would help the person accomplish their goals, and then improve on that with each new iteration.
Jason Cohen talks about MVP being less useful than SLC too. For him the MVP says ‘let users test it for us’, while SLC says “here’s this thing we built that you might like”. He also thinks the second version can progress more smoothly from an SLC too.
Mark Shead has a good video talking about this poster too, which could be used as a pre-class exercise. I like how he also points out that maybe you later discover a need to get to Hawaii. That would be hard in a car, even if you’re using one of those cool boat cars, or a DUCK, as they’re for short distances, and smaller bodies of water. With the Hawaii option you’re also back at the ‘ticket’ option in Kniberg’s post. A ticket gets you from A->B via bus, ferry, or airplane.
This approach also focuses on ensuring components work together as a whole system. Avoid focusing on the perfect wheel, only to find it doesn’t interface with the axle correctly. We can’t use the Johnny Cash ‘one piece at a time‘ approach to build a car.
We also illustrate that because we’re focusing on the whole, the team is regularly talking to each other. Talk regularly, frequently, and you and your team are less likely to get stuck, or to go in the wrong direction. We validate assumptions with short feedback loops, and by regularly integrating everyone’s code.
All of this relates to systems thinking and outcomes: how the client using the application will benefit from the application because this makes their work easier/faster, or whatever. Maybe the team will also develop sequence diagrams to ensure the components deliver the correct useful outputs to speak to each other.
We want people to love or hate what we’re building
Kathy Sierra once wrote that you don’t want people to ignore you. You want them to feel: love, or hate, but not ignore you. This is another aspect of why feedback from clients, and other users is important.
We need to teach our students that users need to love or hate the app the team is building. If users feel ‘meh’ about it, then they’ll forget it. When users hate it, then they can tell use what’s wrong, and we can fix it. If they love it, then they can tell us what’s wonderful and we can build on those aspects. ‘Hate’ shows we broke an assumption in our prototype, and we can fix that.
Sadly, people took to hating Kathy so much she withdrew from the internet in 2007. Look at her other posts too, they are always useful, and are licenced under Creative Commons. Use them in teaching.
Use this in your classroom to improve how teams think about their work
There are a number of things you can do in your classroom to guide students in their thinking and work.
First, have them watch the Shead video. He has an easy presentation style, and has a number of other useful ones too.
Second, talk about Kniberg’s poster in your class. Have students apply it to what they’re building in their teams, and give them a chance to discuss it in the classroom to tease out any issues they might have.
Lastly, see how their work passes the love/hate/meh test. Maybe apply this to something they know already such as burger places, or cafes in town. Which ones are ‘meh’, and why are they ‘meh’. Where do their competitors stand?
This post is part of a project pulling together my materials and ideas about Teaching Team Collaboration: the Human-Side of Software Development for software development to students.
If you’d like to be notified of future posts, then please sign up for more using the adjacent form. When you sign up, then I’ll send you a free copy of the collaboration rules as a PDF from the book. You can also follow me on LinkedIn
The ideas above are from my book 101+ Ideas to Improve Team Collaboration, which covers all of these little things that students can do to improve their collaboration.