Developing an MVP with rapid feedback cycles

I recently offered to help out my personal trainer by writing an application to keep track of the number of reps a member had performed within a set time period. I thought this would be a good opportunity to test out how important it is to keep the users involved in the development process. Here’s how it went.

“I need an app that has a countdown timer where I can set the time. I also want a rep counter on the same screen so I can count how many reps a person has performed without having to keep track myself.”

This was the first statement that included any form of requirement. From this I pulled out some main ideas:

  • The user wants an app
  • The user wants a configurable countdown timer
  • The user wants an incrementable rep counter

I timeboxed the first iteration to two hours with the aim of producing something that worked but that might be a bit ugly. This is what I came up with:

As the requirements were very simple I chose to write the app using Xamarin so that it could be cross-platform compatible. After showing him the first iteration he responded with:

“That’s what I want it to do but I need it to work on my mac so I can put it on a screen during competitions. Can you make it brighter too?”

Clearly, this wasn’t going to work on a mac! I had subconciously made the assumption that it was for use during training sessions as that was only context I was aware of. Fortunately I had only spent two hours so the loss was minimal. If I had attempted to build a polished product before getting feedback from the user, much more time may have been wasted.

So I embarked on iteration two with another 2 hour timebox. This time I aimed to produce something that worked but which was brighter in appearence. I built a simple client side web app using JavaScript:

Screen Shot 2016-06-12 at 19.26.52

The functionality was the same but required an ‘s’ keypress to start, an ‘r’ keypress to reset and a ‘space’ keypress to increase the rep count. The up and down arrows adjusted the timer. Again, I showed the user.

“That looks great! I tried to use it in the gym though and it didn’t work because we don’t get a wi-fi signal.”

I was struck by a second assumption. I had used my phone in the gym in the past but with the luxury of a 4g connection. This was simple enough to fix; I was pulling down a small JavaScript library which I pulled into the HTML file instead.

After around 4 hours work I had a prototype which worked in the intended environment which the user liked the look of. As the user now had something to experiment with, he quickly came up with further suggestions to improve his experience with the app.

“I’ve found I can keep incrementing the rep count after the time has run out. Also, can I get a countdown from 10 before the timer starts.”

The first suggestion was a simple bug fix and the second built on functionality which already existed (a countdown). Overall, five hours was spent to get to a product which was fit for use.

Final Thoughts

  • It is unlikely you will get the full picture through any amount of analysis as users may not communicate what they want precisely.
  • Experimenting and failing fast is far cheaper than building a product that doesn’t satisfy the user’s need.
  • Requirements emerge as previously unexpected boundaries are discovered.
  • Giving users something tangible to experiment with is far more powerful than asking them questions about hypothetical products.
Advertisements

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s