Laying down the rules

So what is an MVP? If you ask that question to 10 people, I’m pretty sure you’ll get a lot of colliding answers. For some MVP is full functionality, but no design, or all UX but nothing behind. Or even as simple as a google form. For me it is a sprout of the product, rather the potential of the product in mind. When doing something from scratch - if it’s a new product on the market, or just an new component in a company’s portfolio - you have to take some losses from your wishlist. What you wished for initially will come to life later, in iterations as the product evolves, naturally.

Classic mistakes in MVP project management

We need feature X

Are you sure? Always ask yourself: Can myself and my company live without feature X for a few weeks? How about months? Do we need that super reporting interface when don’t even have 10 customers? Most of the time the answer will be: you’ll figure it out. Feature X can wait when there’s a need fo feature X. That opportunity will present itself, usually when you do a lot of mundane tasks OR customers asking for it. That’s the right time to spend time on ‘power features’ not in the infancy of a product.

I don’t like this anymore, we have to change it now

No, you don’t. When doing something new, you have to be flexible in many ways, but changing the scope or tools mid-implementation is product-suicide. Have you walked into a restaurant, ordered roast from the menu, and while the chef was preparing it you shouted to the waiter to change it to a rib-eye steak? I don’t think so.

You stick with your initial agreement, there will be plenty of time to change later. Scope changes like this are dangerous to your project as well as developer happyness in general.

Never ending story

You’ve done your homework, wrote down all the requirements, everything is organised. Development started, first few tickets are in the ‘Done’ pile, and then: they stuck there. For days, weeks. They never get accepted by you, the stakeholder, because you always find something bad with it, or a new thing you haven’t thought about.

If you change the scope and never happy then you might as well have one single task on your board saying: “project”. When you set up your stories and tasks, stick to them. Accept them as they were created. If something wrong, just create another ticket, nobody will stop you doing so!

I’d also strongly encourage to use sprints, whether with agile or waterfall, doesn’t matter. Just a simple agreement of deliverables in a small-ish timeframe, like 2 or 3 weeks.

We are in a race

Now, this is complete bollox. You are never in a race. Google was not the first search engine on the web, Facebook was not the first social media site in line and Amazon was not the first webshop. The whole race thing is just empty statement, no substance behind. Look at Wunderlist, that was possibly the thousandth todo app on offer, what brought over millions to use was its simplicity and product feeling. Not because they were super quick to market.

We are not finished until we are feature complete!

Well, actually we can be finished. Just some things will have to wait another sprint or two. Just enough time to gather some feedback from (beta) users, and to review product priorities. It takes some practice to let go full control and demand on features.

You create, release, gather feedback, review. Or in one word: iterate. Constantly change and adjust for the better.