Build a product

From idea to working product that actually is solving something for someone who’s paying for it

As you read in the Starting a Project chapter, building a project is all about trying out the idea fast and see how it’s received, then build on the feedback (as in actions users do, not always what they say).

With that little retrospective we continue the playbook for building a product. A short disclaimer: I’m not going to go in to pre-research such as Usability and User Experience (UX) as that is somewhat covered in the Agile chapter, and it’s really another book, but let’s mention that what your are building must look and feel good.

Great interactivity at the right level. So get some good UX people aboard. It will make a huge difference. Leaving UX to Developers and Managers and it will look like an 1980s accounting system with 1000 buttons. So, no.

Ok, so provided you have a “nice design” (a UX designer would kill me for writing that) next thing to do is to choose which of the features are the least you need in order to make your product viable.

You have a great design mockup with tons of cool features. Say you are building an apartment listing website. You need login, subscribe to new advertisements, search filter, a way to add new listings, sharing them, adding photos, login logs, information pages, payment options for days of listing, admin user management, etc, etc

Which of these are core to the functionality of the application and which are not? All are core. So how do we pick out a few of these in order to build our MVP? Here you go — the most misunderstood thing in the entire MVP-approach is that you must choose “which features”. You can build them all if you want, but you can’t build them “fully” or “entirely”.

Take login as an example. You may not need to have the user use "forgot password” or set a 8 character super safe password or use Two Factor Authentication right away.

Read more in "The CTO Playbook" available on Amazon/Kindle.