Towards defining the minimum viable product

I finished work today on a happy note: the "current" milestone task list became empty!
This obviously leaves the task of looking at the backlog and choosing the next step.


I've got most of the core functionality now, so - given what I've been saying in other posts - the next step is to get a minimum viable product out there. Taking the lean approach, this will be a truly minimum product. There will be obvious gaps in the functionality. The reliability and security could probably be better. The look and feel will take you back a few years. It will be an early adopters product. But the core functions, that define it as an idea, will be there. Anything else? Well, yes. I think there are three stories in my new current task list:

1. The last touches to the core features. Mostly this will be adding a web interface to existing back-end functionality.
2. Pick some metrics and collect them. Errors and page-hits are part of this, but what I'm really talking about are the measures of how people react and how the thing grows - the lean startup's actionable metrics. I've got some ideas about this, but I think they need crystallizing.
3. Complete the continuous delivery loop. I've got CI doing some testing. I've written with a view to delivery, config separated out for different machines etc. Still to be done is automated testing at the browser level and actual repeatable deployment to production - and any wrinkles those things throw up.

The last two points are important, even though they aren't product features. The first tells me about how I'm doing. More importantly, as I change things and add things it tells me whether or not they are improvements (assuming there's some traffic!). I've read the book but I'm still pinning down my metrics. I'm finding the idea is often defined in terms of what it isn't, with reference to vanity metrics. The last point is sort-of optional, but driven by two things: First, I really like the idea of well controlled deployment. Partly that's just the way I am, partly it is pragmatic as my work will distract me from this so it needs to be smooth. Second, this is minimum viable product. I've got 69 tickets on the backlog and am about to start experimenting. Frequent change with minimal cost has to be the way things are. A/B testing will follow soon after.