Thinking Out Loud

Only include what you can build

Don’t prototype features or functionality that cannot be implemented.

How many times do you get a nice looking PhotoShop design as your brief? It’s nicely sliced and diced ready to roll. Sweet. You are really happy, because the client has clearly got his shit together.

You start translating into HTML/CSS or binary code, or whatever you use, and about 24 hours into it, you’re looking at the details of, say, a harmless dialog box. This is the first time you read the little 8pt notes – and the wording says “search our suppliers’ databases, and return a formatted word document summary”.

Wow, you think, that’s an awesome idea.

The only trouble is, (a) the suppliers do not grant access to their database, (b) most don’t even have a searchable database, (c) there’s no way on God’s green earth that you are going to be able to format in Word, and (d) would all these suppliers actually allow you to munge their data in with their competitors and displayed on your app as your own?

Bother. So you go back to the client, ask what this little dialog means, and they say “Oh, well, we thought this would be great on the demo. It will let our potential customers see the awesome stuff we have in mind for the launch release.”

“But what about a, b, c, & d (above)?”,  you ask them.

“Oh, well a, b, d, I guess you’re right, but we saw someone else format things kinda like Word once. So (c) is proof that we can do it. Maybe you can do one of those cluster-the-cloud techie things. You know.”

This project not only raises 100 red flags, but it’s this sort of thinking that will come back to bite you in the bum. Not during alpha or beta phases, but probably about a week before the launch party (once all the marketing budget has been locked in).

The early test audiences, focus groups, pre-sales results might be totally based on this one awesome feature.

The one awesome feature that nobody has any clue how to actually build. (Well, there’s a rumour that some guy in Slovenia can do it, but only if you get his whole family residency visas, and hire his cousin.)

But when you get to launch, everyone says “Where’s that awesome killer feature we saw in your prototype? The one that I’ve been telling everyone about. Show us how it works, and we’ll drop shit-tons of money in your lap right this instant.”

“Well,” you say “we removed that since you saw the prototype, because it just didn’t work. Only a couple of our suppliers could provide data, and only if the other was hidden, and of course you can’t format 700-column tables in Word, and there were some legal issues. But hey, look how you can pick your own avatar in the social sharing screens…”

You forgot the “Viable” bit of the MVP.

When you are building a prototype, and you don’t quite know if some small part will work, then don’t show it to anyone until that small functionality has been proven. I’m not talking about common stuff that’s a variation of something you or everyone else has done a dozen times, just the stuff that is a kinda-new idea, or if it’s central to your concept.

Try leaving it out. If your idea still works, then it shouldn’t be included in your MVP prototype. If your idea just doesn’t work without it, then you’ll need to figure out how to make it work, before you go any further.

You might like to build a Functional Model first – some simple little single-purpose bit of code that demonstrates that you can, indeed, hook into suppliers databases, and format the results. You don’t need anything pretty, and nobody is going to look at it. It’s just a proof-of-concept tool.

Then you can go ahead and happily make a prototype, complete with the pretty little dialog box – without your awesome feature working at first, because you have proven to yourself that it will work in the end.

Or, if your Functional Model fails, then you don’t even have to build a prototype of the app at all.
Cheap, quick, risk eliminated.
Time to try another idea.

Add comment