Blog

enterprise-architecture

Of blocks of wood and why we draw models

2015-05-14-why-we-draw-process-models

Every March for the past 4 years, a bunch of lunatics around the globe have spent one manic weekend trying to invent and design a new business service. In that weekend, they have to use one single word or image to inspire a new product. It's called the Global Service Jam, and it's since spread to launch two other worldwide events, the Global Government Jam and the Global Sustainability Jam.

I've been involved twice, I was a participating lunatic last year, I was a volunteer helper lunatic this year. Next year I'll probably participate again.

Yep, they're basically hackathons for service designers. An exhausting but rewarding experience, and anyone who cares about innovating should do it at least once.

One of the key activities in these jams, like in all service design, is getting feedback and buy-in. And so you go through a 'prototyping' phase, where you try out what your team has managed to think up, with your target audience.

Now, like a lot of people in this space, I come from the traditional route of programmer / solution delivery, and when I hear the word prototype, I hear 'stripped down version of the final product to get feedback'.

Yes and no. Feedback - yes, product - no, no, no.

Let's look at the desired end product here – feedback. A prototype is *anything* that lets your target audience understand what you are proposing and give actionable feedback. In sales, you learn that the worst result is a neutral result. “Exactly what we want” is what you hope to hear, sure, but “no use to us, and this is why” is still far better than “hmm...I don't know...can't really decide...”

And that's what a prototype is – whatever will enable you to start a productive discussion to get real feedback, identify flaws and figure out what you can do to improve the solution.

Which brings me to the block of wood. Most people reading this will hopefully remember the PalmPilot, the electronic personal organizer that came out in 1997 and which some people might think of as the Ford Model T of the smartphone world. What a lot less people will know is that the prototype Palm Pilot was...a block of wood. With some buttons written on it. In biro.

Silly? No. The product manager would literally walk around with his block-of-wood Palm Pilot in his pocket and take it out and role-play tapping on the buttons while explaining. It was, pure and simple, a prop.

“I wonder where this becomes relevant to my job”, might be a question at this stage in our rambling anecdote. And the point is this – no prototype is something that you could sell (at volume), but they get you to something that you could. No model creates the actual service or reduces the costs by itself, it’s the insights that they provide.

Which is the takeaway from the anecdote. A model is not supposed to be the thing that you are modeling; it is supposed to help you (and others) gain insight. Which means that you should only include enough detail to enable understanding, insight and (hopefully) feedback. You’re not delivering the architecture, you’re designing it.