Making MVPs Work

I feel like we’re still struggling to put MVPs to work, which I 100% understand and empathize with. One issue is the only real forcing function that we have today, is the release length itself. Our context of estimating may be seen as, “could I finish this in 3 months?“. Parkinson’s law says work expands so as to fill the time available. 🤔

Flipping this backwards could help us identify MVPs. For example, think of a feature — say we want datagrids to auto-refresh. What could you build if you had three months? What about one month? What about two weeks? Sure the latter won’t have all the bells and whistles, but could it work? The folks at Basecamp have codified what they call “appetite”…

…we focus less on estimates and more on our appetite. Instead of asking how much time it will take to do some work, we ask: How much time do we want to spend? How much is this idea worth?

It’s like the return on investment (ROI) of building a feature. The ROI of auto-refresh datagrids if we spend one month is high, but not a great ROI if we end up spending six months. In the Basecamp book, they talk about adding a requested calendar feature — they knew the complexity would require at least six months, but didn’t have the appetite for that. Instead, they settled for a paired-down “dot grid calendar” to satisfy customers while spending less time.