Andrew McGill

Excited by the latest news platform? Build three — yes, three — prototypes to test it first

Reposting something I wrote for The Atlantic’s product blog..

We have so many toys. If you’re a developer, I’m guessing there’s a new framework you’re itching to try tomorrow. And if you’re a news developer, or involved in news product development, there’s even more to tempt you—AMP Stories, ARKit, chatbots, podcasts, IoT, that 3D graphics library you never manage to find time to crack open…

All of this stuff is awesome and you should use it to make great journalism. And yet… haven’t we all been in this position?

Product manager: Guys, Facebook just released a new feature where you can post a picture of yourself smiling, and it’ll make a hot-dog dance next to your face. What could we do with this?

Excited developer: Oh man, so many things! (skims documentation) And it’s so simple! We need to get on this platform immediately!

Product manager, now also excited: OK! Let’s build something! How many sprints will it take?

Boss: Uh, hold on a second…

I am intimately familiar with the rush of adrenaline that comes from hearing about a new platform or technology and needing to build something with it, immediately. But what if the platform is more annoying to work with than you expected? Or it isn’t a good fit for your users? Or — and this is always the heartbreaking one—what if you just don’t have a good enough idea of how to use it?

Our team at The Atlantic is mighty and growing mightier, but we’re still small enough that we have to choose our shots carefully. So here’s a proposal: Before you go whole-hog into launching a creative initiative with new tech, build three completely different prototypes first.

Prototype, prototype, prototype

By “prototype,” I mean a thing that is proudly held together with duct tape. It is the minimum of your minimum viable product. It is hopelessly bespoke.

It is also a crucial first step. Without getting your hands dirty, I find it’s very hard to get a sense of how a technology could fit into your systems and editorial workflow. Also, your audience (or a small slice of them) can play with a prototype. Who knows if they even want the latest journalism-hot-dog mashup?

Here’s the bottom line. If you’re going to spend a bunch of time reading documentation to make a level-of-effort recommendation to your boss anyway, why not make something while you’re at it?

Well, not something. Three things. You have to make three things. What’s so special about the number three?

• It’s not one. Your first idea for this platform might be complete magic. But never test just your first idea. You’re too enthusiastic about it to be objective.
• It’s not two. Two ideas means you have a winner and a loser. Don’t give your brain (or your bosses) an excuse to ditch the insights from a “losing prototype” because you built a duopoly. You need to learn from both.
• It gives you permission to move fast and be imperfect. When you’re just building one thing, you’ll want to make it perfect. Building two things is definitely a grind, so you’ll end up putting 75 percent of your effort into the idea you like better. But when you have to build three prototypes, all those excuses go out the window. You don’t have time to focus on your favorite, and no one’s expecting you to come up with something production-ready.

So those are the rules. Get excited. Build three things. Put them in front of people. Then figure out the next step.

How we did this with the Amazon Echo

The Atlantic is no stranger to audio — we have two podcasts we love and a slew of audio articles. But we haven’t built anything for smart speakers like the Amazon Echo or Google Home.

We knew we wanted to. But the prospect of having to learn an unfamiliar SDK and the difficulty of coming up with a worthwhile idea that could also attract sponsors meant smart speakers always got pushed to the back of the line.

In February, we resolved to break the stalemate with a prototyping blitz. Oh, and do it within a month.

• On Day 1, we pulled newsroom editors, product leaders and sales reps into a conference room. Their topic of debate: How could smart speakers improve The Atlantic’s journalism, and also present an attractive opportunity to underwriters? Together, this larger group hashed out a few broad areas of interest — quizzes, archive material, scientific and cultural discoveries, and non-political news content.

• We then whittled the group down, keeping only the key stakeholders. They refined the broad areas and came up with a list of “prototype candidates” — around a six or seven ideas. (A requirement — they had to have goofy names.) To help the group see potential costs, I found it helpful to plot how hard they would be to build versus maintain, using a chart like the one below:

• Voting time! From that smaller list, the stakeholder group picked three ideas to rapidly prototype and test with readers. They ending up selecting the two flash briefing skills, as well as one custom skill. Remember, you have to build three!

• The Atlantic Product team got to work. For each of the feed skills, we produced a week’s worth of “episodes,” pulling talent from the newsroom to help us write scripts and line up interviews. The custom skill required a bit more work in Node, but also a fair amount of voice acting — let’s just say we discovered some emerging radio talent from the ranks of Atlantic developers. All in all, building the prototypes took two weeks.

• Simultaneously, we recruited beta testers from our readership. We’d give them things to listen to over their smart speakers, and they’d fill out a survey after every episode/interaction. We’re lucky to have dedicated Atlanticans who are willing to play around with what we create.

• Launch day! All three products went live to various segments of our beta testers. Before long, we started getting feedback through surveys (and by surveys, I mean Google Forms, because what else do you really need?):

• This real-time feedback was super helpful, and allowed us to switch things around in the second week of beta testing. By the end of the week, we had hundreds of responses — tons of quantitative and qualitative data to pore through.

• It’s over! We convened a wrap-up meeting to discuss what we learned and what products we wanted to build next.

That was our prototyping blitz. At the end of it, we had a) three working products, b) lots of data about customer preferences, and c) tons of enthusiasm for the next steps, both on our team and among our readers/testers.

Maybe you don’t have the time for this approach. (I’m betting you do.) And perhaps the technology you’re looking to test is just too complicated to cram into a one-off prototype. (Is it really?) If that’s the case, I guess you just have to wing it.

But if you’ve got any flexibility in your pipeline, give yourself permission to rough out a new thing (three things!) and learn along the way what you really want to create.