Episode One Hundred and Eleven: If You Want To Make Products; Enterprise Driven Software Development; Odds

by danhon

0.0 Station Ident

I’m on a bus on the way to an undisclosed for NOSTROMO BLACK.

1.0 If You Want To Make Products

Then hire product people.

I was thinking about yesterday’s episode[1] and the mini-rant in which I attacked Peter Levitan for suggesting that advertising agencies make hiring computer scientists and engineers a priority over, well, anyone else. Peter’s thesis is that agencies need to get out of the business of making ads and chasing after the next Lion because they’re the epitome of short-termism. The real value, the thinking goes, is to produce some sort of reusable IP in a product or service where you can increase your margin.

It took me a while to figure out the root cause of why I felt uncomfortable about this, and I think it’s an illustration of inaccurate thinking as to what it takes to make something that’s not advertising.

Let me first say this, though: making good advertising, like good anything-else, is hard, difficult, painful and necessarily involves a whole bunch of people and herding them in the right direction. You are, in essence, talking about a creative endeavour. What’s interesting about advertising is that, from an outsider’s perspective who spent four years in it, it can sometimes feel a little bit weird. I mean: the traditional setup is something like this – your client and your planners work on a brief, account management makes sure everyone’s happy with it, the creative directors assign a team and the copywriter and the art director go and have a think. They come back with some ideas that then get turned into scripts, that may or may not be storyboarded, the client agrees that these are pretty good ideas and then you go out and production talks to lots of production companies and directors to see who might make the creative team’s idea. The production company and the director then produce a treatment which is their vision of how they think they can bring the creative team’s idea to life inside all of the constraints like budget and time and talent and all that kind of thing, then everyone goes to LA for a week and eats themselves silly on craft services and sits in the video village, which is where you have the folding chairs and watch what happens on a monitor while the director does their thing and directs the advert. Sometimes the director will come over, or the team will send a note to the director and there’ll be a conversation about: perhaps we should try this, or, you know what, we really need a shot of the logo here, or, “I’m not really feeling it from that actress” and “could she try to open the app again, but smile this time”. And then an editor gets all the film that’s shot and starts assembling it into a rough cut and it’s probably terrible, so you lock the copywriter and the art director and the producer in a small room for about another week and you don’t let them out until they’ve massaged and edited the film into something that actually a) tells a story and b) does the job that the brief asked it to do.

I write all this out longhand, because if you’re not familiar with making software – products or services – and your entire experience has been with making film, then you’re going to have a rude awakening. Or, rather, you’re going to fail. Hard. And often.

Because, unless you take the time to understand all the people who’re involved in the process, you’re relying on institutional osmosis through learning. The analogues are only analogues – they’re not direct translations.

Who’s the director, for example, in software development? Ultimately, a creative team can tell a director what to do. The director is a hired gun, for example. Sure, the director has made films before. And obviously the best creative partnerships are those where they’re a partnership and the creative team can see things that the director can’t and vice versa and they push each other to make better work.

I’m pretty sure I’ve written about this before, but the worst case scenario is that you get someone like the Winklevii saying “Hey, we’ve got an idea for an app” and before you know it someone’s gone off and called up a production shop and, well. It gets a bit embarrassing.

All of this is to say that there are skills that are valuable in making *advertising* that are not necessarily translatable to product design or service design. There are certainly skills at the soft front-end in terms of thinking creatively about solving a problem that will get peoples’ attention. Or that might spread. You know: ideas for things. But, as they say, the devil is in the execution.

When you’re dealing with large teams, it’s incredibly important to make sure that roles, responsibilities and respect are established. People need to know who’s good at what, who’s responsible for what. For good creative people – whether they’re put in the “art director” or “copywriter” bucket, who are smart and able to come up with good insights and contributions, one of the biggest problems is a failure of communication. Because there hasn’t been practice, it’s hard to find common ground to express what it is that you actually mean because, more often than not, the tools that we have available to us (conference calls and email and Basecamp, for example) for giving useful feedback consistently fail us. At the worst case, for example, when you have a team who want to have input on how an object behaves in a simulated physical environment, how do you describe how you want it to act in feedback? Less bouncy? More bouncy? More springy? When you have to build-deploy-install-gather feedback, the loop is slow and irritating.

And yet, part of this is why you lock the creative team in a small room with an editor for a week. In the filming process, you grab all the bits you think you’re going to need, and in the editing room, you frantically assemble them into something that (hopefully) works. And you should get better at that process over time, having a good idea of the kind of shots that you might need, of the ways that you can assemble things. Non-linear editing is a great tool for helping that.

Here are some of the areas that a creative team will or should have input on for a shoot, after writing the script:

– the selection of a director, from the gathered treatments

– casting

– location scouting

– wardrobe

– props

– lighting

– camera angles

– editing

– music

– voiceover casting

– voiceover recording

– sound design

– colour correction and grading

– title and card design

When traditional agencies are asked to provide interactive or digital solutions to briefs, they’re commonly asking teams whose skillset is in the above areas because that’s their experience. You’re then asking a team that’s used to that level of involvement – of being able to pass quite detailed notes to a director – to then, essentially, direct a software experience for a product or a service.

And then you’re asking them to do it with no user testing period, most of the time – because who’s got enough time for that? Typically testing and QA will cover the type of “does it have a bug” testing, not “does it do what it’s supposed to do” testing, and you’re lucky if you even have that amount of time for testing. (Conversely, you can be unlucky and have an overly corporate client who requires an unreasonable amount of testing and QA and then you have other problems).

So you have an environment that has fostered a certain level of control inviting teams to exert the same level of control on something they haven’t done before that is *as complex, at least* as making a piece of film. Only I’m going to be honest and to say: making good software is potentially orders of magnitude *more* complex, because hey, you’re talking about an interactive experience. It’s non-linear. It has multiple states.

When you’re talking about building a great product or service that *does something*, there are analogues to each and every single one of those areas of responsibility or input that need a considered decision. And, obviously, they’re areas for which there are established norms. Whilst software might not be as old as the language of film, it has its own conventions and expectations. And it’s also an incredibly malleable medium. There are things that you can do in software that sometimes you *shouldn’t* do, or you shouldn’t even be able to do. Sometimes that’s good, because it means you can make something surprising. Sometimes, not.

So in the same way that making a great tv spot is a team effort, so is making software. And one of the first steps is making sure that you’ve got the right team. For a long time, knowledge of “interactive” in agencies was so bad that being an interactive person meant that you were expected to be able to deal with the entire domain. This would be like saying you were a “film” person and you were expected to be able to execute and have a professional opinion on *everything* to do with making a piece of film. But again, obviously, there are specialists and specialisms. It’s why we have interaction designers, it’s why we have frontend developers and backend developers and devops and so on.

The gist of this is: if you want to make product, then you need leadership that understands how to make product and can teach teams how to make product.

If you hire only software engineers, you’ll only get the builders. And you absolutely need builders – to build the thing. But it doesn’t mean you know people who know *what* to build, or how it should function or, even, how you can sell it to a client. Because selling an ad and selling a product or service are very different things, *especially* when your clients expect ads.

Whether that’s product strategy or design or research or whatever: product management simply isn’t a discipline that exists at most traditional agencies. And product management isn’t a thing that’s at the top of a software engineer’s skillset either. It’s a completely different thing. But, it does rely on some of the core competencies that agencies pride themselves on: understanding how to make a connection with people.

[1] Episode 110, 1.0: Stop Hitting Yourself

2.0 Enterprise Driven Software Development

After that, be forewarned: this bit is *really* dumb and silly. It’s Yet Another Star Trek: The Next Generation bit.

So here’s a new model for software development that can become a cult and a whole bunch of people can follow. It’s Enterprise Driven Software Development, and in it, everyone gets to pretend to be a castmember of Star Trek: The Next Generation and roleplays the kind of software that they’re designing.

Look, it’s really easy:

Counsellor Troi obviously speaks for the user because she’s the empath. She’s super in-touch with user needs and will tell you whether your users are feeling distress because of the confusing modal dialog you’ve just implemented.

Lieutenant Commander Worf is all about Verbing Things and Doing Action Now. Mainly, your software should make pew-pew noises.

Lieutenant Commander Data is the stakeholder who’s going to point out that you literally said that the thing would do that thing and now it’s not done that thing, you’ll have to explain it to him like he’s five, please.

Commander La Forge will purse his lips and basically tell you some sort of dev ops story about how you really shouldn’t be using this to do that, but I suppose you could do, and then it all turns out to be fine apart from that one time the ship’s computer became sentient and then *we never spoke of it again*.

Commander Riker just wants to know if you can a) hide porn in it, b) search for porn using it, c) turn it into some sort of subspace-range Tinder app or d) use it to play the trombone. He is essentially the troll, who will break your app.

Wesley Crusher is a reminder that everyone on your team – even the precocious teenager – is able to contribute solutions to the problem.

Doctor Crusher is there as a reminder that sexual tension is never a good idea on your team, and you should just keep it simmering for about seven years.

Captain Picard has an unswerving faith in daily stand-up meetings in his ready room and basically is the good kind of product director who cajoles every team member when needed, plays the flute in his downtime and has an idiosyncratic way of responding to Jira tickets by requesting that there be a “Make it so” option in the dropdown.

3.0 Odds



You should pay attention to the Activité because it’s a watch that happens to be smart, instead of a watch that needs to scream to the entire world that it is smart and appears to have some sort of chip (ha) on its shoulder about never being taken seriously for being a smart thing. Because the Activité is a watch first that only just *happens* to have a three-axis accelerometer inside it that can measure your activity and wirelessly sync it with your phone. It doesn’t have a display. It’s just connected and smart. I mean that is fucking *brilliant* compared to the “Ok Google, Get Me A Car” stuff that we saw at I/O.

Also, I don’t think this is *entirely* because they’re a French company, but there’s basically a) lots of attractive people, and b) lots of exposed skin on that Withings site and it’s almost feels like I accidentally opened a copy of Vogue instead of navigated to a Smart Things website. Well done, Withings, with the art direction and photography. Ten house points to you.

Next up, Whirlpool emailed me to tell me in breathless terms that their washing and drying machines now Work With Nest! Which is great because I’ve always wanted my thermostat to be able to talk to my washing machine behind my back. Anyway, minus several million house points to Whirlpool for the quite frankly stupid URL[2] for the smart washing machine, and then also minus several million house points for the following infractions:

– detergent cartridges, because hey, you want your washing machine to be like your razor or your crap coffee machine that George Clooney likes

– having a “built-in suite of Laundry Apps includes features like Stain Assist and Hints & Tips that give practical advice on stains and other everyday laundry questions.” whereby it *sounds* like washing machine programs have now become Apps because Apps

– a Smart Nudge, which must be better than just a Regular Nudge

– some Smart Energy which likewise

– Smart Stats via Sixth Sense Live (TM) which amongst other things, will let you look up how many days your washing machine’s been online because, I don’t know, you want to measure its uptime? You want it to cut back on its internet usage?

– a full colour widescreen LCD display that probably isn’t a touchscreen.

Bad Whirlpool and your badly named washing machine. Watch the Berg Cloudwash video one hundred times before you come back tomorrow.

Matt Jones wrote up notes from his session at Foo Camp[3] and we should all applaud him because he’s been blogging again which is great but also makes the rest of us look bad because he’s so smart. Anyway: the whole idea of all this (great?) ideas that were essentially unexecutable due to insufficient tech-tree advancement when the Civilization that discovered them was in play. In other words, technological advancements in computing, communications and materials science mean that we can (possibly) do all these things that were undoable before, never mind the fact that fusion is still a few decades away. Examples? Zeppelins. Balloons. The Memex. The Hitch-Hiker’s Guide. Virtual Reality. Micro-economies. Micro-lending. Digital currencies. There’s a whole bunch of this stuff.

It’s also interesting because it points to the suspicion that we’re inherently lazy as a species. It’s just so much work inventing *new* stuff when we can just dig up the recent(ish) history and then figure out how to do it properly. Is this different than Hollywood taking beloved old IP and then showing what can be done with an outsourced renderfarm and hundreds of match-move artists?

[1] The Withings Activité

[2] Laundry-dash-one-slash-Laundry-dash-two-slash-Washers-dash-three, really?

[3] All of this has happened before and will happen again

As ever, you should send me notes. Because I eat them and they sustain me.