The “V” in MVP

How to get an MVP that is actually viable

The way to get startup ideas is not to try to think of startup ideas. It’s to look for problems, preferably problems you have yourself.

Paul Graham

We built dumpstr out of necessity. We needed knowledge management for our team and we needed it to be straight-forward and hassle-free. There’s much going for why you should build a product that solves an actual problem you and your team have. We like to sum it up as follows — When you build something you need, you build something for all people who are like you. Naturally there’s a lot more to it, but that’s a really good start.

Solving your own problem means you should be the first to use your product (awesome). Once we established that, we were itching to start working with dumpstr. So how did we go about that?

Your UIP (Usable Internal Product)

Build a working usable prototype for internal use

This is different than building an MVP for your early users. A UIP can be ready long before an MVP.

Building for internal use of your team means there are certain areas you can push into the future in order to test others right now. And it also means you strive to start working with your own product ASAP.

Ask yourself, what should we build first for our product to be internally usable?

Our UIP — a working example

*** We’re going to talk about dumpstr’s UIP, we promise to keep it relevant ***

[Inhaling deeply] dumpstr is an extremely simplistic take on collaborative knowledge management. When conceiving the idea, we felt that we lack a tool to document essential knowledge we called TIDBITS — thoughts, ideas, decisions, brain dumps, info-pieces, tiny-documents and side-notes. Google Docs felt too big and awkward for these, Evernote required too much investment, sending yourself emails is just weird, etc. We also wanted to bring some of Gmail’s no-organizing magic to a folder-oriented world. So we kept it simple — notepad + zero-organization philosophy, wrapped inside a lean and clean feed with awesome search on top. That was our UIP. [Inhaling deeply].

We bootstrapped it so WE could use it = Node.js + Express, AngularJS, quick security setup (Stormpath), small non-scalable MongoDB deployment and a simple UI with zero-shticks. It took us 3 weeks and dumpstr stood on its own two feet. Sort of.

We immediately started using it and found out that dumpstr was great for documenting our conclusions and decisions, saving code snippets, our thoughts and decisions. But it had serious problems too: our text search engine wasn’t getting all the results we wanted and our collaboration mechanism (based on ‘rooms’) was too simplistic.

The value — we started iterating in order to make the product usable for our team. To improve search we’ve build our contextual search (a wiki-like link navigation that allows searching based on time or location of entries), we tweaked our collaboration mechanism by making it email based, and we implemented continuous scrolling for our feed. These are all features that could only come out of actually using the product and seeing where it failed us.

As time progressed, serious data has accumulated in dumpstr and we’ve come to rely on it (over 1K entries, 10 average searches per day). That made us more confident that our product can actually bring value to people like us — people in search of a way to capture and consume TIDBITS of knowledge.

Another “side effect” was that using our product in our team early on made us really critical towards it. For us, that was and still is a good thing that constantly drives us to make dumpstr a usable problem-solving product.

UIP—puts the “V” in MVP

Using your own product while building it is a bootstrapping process, much like bootstrapping your startup. And it holds much of the same benefits.

The feedback cycles are super short, you learn from the inside about the viability and usability of your product, you catch major bugs before they happen to other users (like, let’s say, a bug that deletes the entire DB), and you become confident about your product’s philosophy.

The end product of this iterative bootstrapping process is your MVP, built in with the viability and confidence of your own team’s every day usage, and polished enough (but not too much) to test with real users.