POINT OF VIEW

Rotman Management Magazine - - CONTENTS -

Ryan Ja­coby

re­gard­less of in­dus­try, EV­ERY LEADER, needs to pos­sess the abil­ity to build a great team and sup­port it. But as teams go, in­no­va­tion teams are unique. Re­search shows that in­no­va­tion ben­e­fits from a high de­gree of di­ver­sity, tech­ni­cal depth and peo­ple with com­ple­men­tary mind­sets and process ten­den­cies.

Lead­ers don’t al­ways get to choose their team mem­bers from the start, so they of­ten need to nudge peo­ple to find new ways to work, even as they ac­tively bring peo­ple in or move peo­ple out of the group. Fol­low­ing are five prin­ci­ples for lead­ers of in­no­va­tion teams to keep in mind.

These are peo­ple with a track record EM­BRACE THE ‘BUILDERS’. of get­ting things into the world in some way, shape or form — hope­fully within your or­ga­ni­za­tion and hope­fully in dif­fer­ent en­vi­ron­ments. Some­times scrappy and en­tre­pre­neur­ial, they ex­hibit in­tense cu­rios­ity, value con­tin­u­ous learn­ing and are will­ing to try new things, wel­com­ing as much feed­back as pos­si­ble.

Builders aren’t go­ing to wait for you to tell them what to make, and they’re rarely go­ing to show up with a sin­gle idea. They’ll bring sev­eral ideas to the ta­ble, usu­ally right from the start, even if they don’t com­pletely be­lieve in each. Make sure you have peo­ple who are not only gen­eral builders, but are ca­pa­ble of build­ing the types of in­no­va­tion you’ve pri­or­i­tized — whether it be in the realm of ser­vices, tech­nol­ogy, chan­nels, part­ner­ships, or mar­ket­ing. Once you’ve got them, use them well. If you’ve got builders sit­ting around wait­ing for strat­egy to hap­pen, you’re go­ing to be deal­ing with de­creased mo­ti­va­tion and moon­light­ing.

Frank Hauser’s Notes on Di­rect­ing is a clas­sic com­pen­dium of ad­vice for the­atre di­rec­tors work­ing with ac­tors and crew. Writ­ten as a series of brief apho­risms — like ‘Don’t ex­pect to have all the an­swers’, the book is filled with tips that are equally use­ful for any­one work­ing in cre­ative col­lab­o­ra­tions. One such pithy piece of ad­vice is: ‘Never keep the tal­ent wait­ing’.

Some peo­ple love gen­er­atDIVERSIFY AND BAL­ANCE THE TEAM. ing ideas, but are less en­er­gized about ex­e­cut­ing them; oth­ers love plan­ning and re­search, but get anx­ious com­mit­ting to a di­rec­tion. It is your job to find the right mix of at­ti­tudes and ten­den­cies — and to cor­rect for de­fi­cien­cies as you go along.

One com­mon prob­lem I have seen is a team weighted to one ex­treme or the other. These teams keep spin­ning their wheels (mov­ing Post-its and gen­er­at­ing ideas with­out get­ting to any­thing con­crete) or jump the gun and start de­sign­ing in ex­cru­ci­at­ing de­tail the first idea that ma­te­ri­al­izes. Of course some­times the first idea is the right idea, and some­times we re­ally don’t know enough about the cus­tomer. Too much ex­plor­ing or too much ex­e­cu­tion can be coun­ter­pro­duc­tive. You need to find a bal­ance of in­sight and ac­tion, pro­to­typ­ing and strat­egy.

Find peo­ple who are able to com­mit the DE­MAND DED­I­CA­TION. time and en­ergy to the project. Your team mem­bers should be able to com­mit six un­in­ter­rupted hours four times a week, or they’re off the project. It is even more im­por­tant for your team to be ded­i­cated than for it to be cross-func­tional. I’d rather work with a bal­anced, di­verse three-per­son team who are ‘all in’ than 15 peo­ple who cover ev­ery di­vi­sion of the com­pany but can never find time to do the hard work.

In my ex­pe­ri­ence, teams that do OWN THE WHOLE PROB­LEM. this are more suc­cess­ful and build bet­ter in­no­va­tion. Em­brac­ing the whole prob­lem means:

• Iden­ti­fy­ing cus­tomer prob­lems;

• Dis­cov­er­ing and dis­till­ing cus­tomer in­sights;

• Pro­to­typ­ing and get­ting feed­back on ideas through ex­per­i­men­ta­tion;

• De­sign­ing win­ning so­lu­tions and value propo­si­tions;

• Cre­at­ing busi­ness model op­por­tu­ni­ties and im­pli­ca­tions; and

• Get­ting new of­fer­ings and busi­nesses launched.

Ideally, all team mem­bers should be pro­fi­cient, or at least, in­ter­ested in all of these as­pects of the prob­lem. Other­wise, you’ll miss out on the true value of a mul­ti­dis­ci­plinary ap­proach.

As The New York Times was ex­per­i­ment­ing with build­ing its ap­proach to dig­i­tal prod­uct de­vel­op­ment, it learned that a good ini­tial team would be com­posed of a prod­uct per­son, a de­sign per­son, a tech­nol­o­gist and an edi­tor, with sup­port from mar­ket re­search. De­spite their dif­fer­ent back­grounds, every­one was ex­pected to care about the cus­tomer, the so­lu­tion, the busi­ness model, and the im­por­tance of every­one else’s tech­ni­cal do­main.

As you watch your team in­ter­act, no­tice their pat­terns so that you can ad­just for im­bal­ances. Pro­duc­tive dis­agree­ment is fine — in fact, you want di­ver­sity of opin­ions as well as di­ver­sity in gen­eral — but you want your whole team to be in­vested in col­lab­o­rat­ing and own­ing the whole prob­lem. If there’s some­one on your team with valu­able ex­per­tise that is not be­ing uti­lized, that’s a prob­lem, and it’s the leader’s job to rec­og­nize it.

Even the wrong prob­lem can get you started on dis­cov­er­ing the right one.

In­no­va­tion is hard work, and FREE PEO­PLE UP TO DO THE WORK. you have to help your team mem­bers stay fo­cused on solv­ing the prob­lem. That is near im­pos­si­ble if a sig­nif­i­cant por­tion of a team’s time is fo­cused on cre­at­ing pre­sen­ta­tions to get stake­hold­ers up to speed on what’s hap­pen­ing. Shar­ing what they’re try­ing, what they’re learn­ing and what they’re build­ing is im­por­tant, but don’t let ‘re­port­ing’ be­come an end in it­self. As a leader, you should help shoul­der the bur­den of sta­tus re­ports and ex­ec­u­tive up­dates. Con­sider en­cour­ag­ing teams to use ‘stand ups’, es­pe­cially with ex­tended teams. In a stand up, the en­tire meet­ing lasts 15 min­utes, with each per­son sim­ply shar­ing progress made yes­ter­day and progress to be made to­day.

To keep things push­ing for­ward, use dead­lines SET THE PACE. cre­atively. A trick I like to use with new clients is to sched­ule cus­tomer feed­back ses­sions as soon as a week or two into work­ing to­gether. When we sched­ule these ses­sions, we don’t have any­thing to show yet — but know­ing that cus­tomers are on the cal­en­dar gets the team mov­ing, ex­press­ing their hunches as pro­to­types, and helps to re­move any re­sis­tance to spend­ing time with cus­tomers. This is what the Lean Startup and cus­tomer dis­cov­ery peo­ple are do­ing when they force work­shop par­tic­i­pants to ‘get out of the build­ing’.

The same type of think­ing can be use­ful later in a project. Ag­ile soft­ware de­vel­op­ment of­fers lots of tech­niques and meth­ods for assess­ing work and set­ting sched­ules, but not all in­no­va­tion is soft­ware-based or solely soft­ware,

so you have to find other ways to set dead­lines.

When we were tran­si­tion­ing from the early stages of defin­ing what would be­come NYT Cook­ing, The New York Times team had to de­cide what in­ter­ac­tions and fea­tures would go into the first pi­lot. In­stead of de­bat­ing the in­ter­ac­tions and fea­tures, we set a date in early De­cem­ber and used that to help de­cide which fea­tures were most im­por­tant to test our as­sump­tions and that we’d be able to ex­e­cute rea­son­ably well. When asked by the team why we chose this date, I said we’d want to be done with de­vel­op­ment by Thanks­giv­ing and run the ini­tial pi­lot in early De­cem­ber be­fore the hol­i­day sea­son picked up. The truth is, there was no real rea­son other than to keep things mov­ing.

Fi­nally, some tac­ti­cal ad­vice for mov­ing for­ward once your team is ready to go.

1. Form a prob­lem state­ment

It’s be­come cliché, per­haps, but it’s still im­por­tant to ‘fall in love with the prob­lem, not the so­lu­tion’. Don’t hurry through find­ing a prob­lem state­ment, but don’t ag­o­nize over it ei­ther. Just throw some­thing out there and start to re­fine it. Even the wrong prob­lem, so to speak, can get you started

on dis­cov­er­ing the right one. If you’re stuck, start ex­plor­ing as­sump­tions you have about the ba­sic mo­ti­va­tions and be­hav­iours of cus­tomers. A good def­i­ni­tion of prod­uct de­sign comes from the de­signer Keenan Cum­mings: “Rec­og­niz­ing pat­terns of hu­man be­hav­iour, dis­cov­er­ing the mo­ti­va­tions and im­pulses that drive those pat­terns, [and then] cre­at­ing [of­fer­ings] that im­prove or el­e­vate the out­put of those be­hav­iours.” Un­der­stand­ing those pat­terns of be­hav­iour, mo­ti­va­tions, and op­por­tu­ni­ties will get you well on your way to defin­ing the prob­lem.

2. Use strate­gic ques­tions to guide dis­cov­ery.

A ques­tion can only be con­sid­ered ‘strate­gic’ if it has an answer that will make or break the so­lu­tion or val­i­date or in­val­i­date an as­sump­tion. Strate­gic ques­tions might be as far­reach­ing as, How are to­mor­row’s cus­tomers dif­fer­ent and sim­i­lar to to­day’s? And, What reg­u­la­tory changes might im­pact our po­ten­tial so­lu­tions? They also might be ‘small’, yet im­por­tant like: What does ‘fun’ mean in the kitchen, when cook­ing a meal? Or, How much va­ri­ety in recipes is ex­cit­ing and how much be­comes too tax­ing?

I like to draw a dis­tinc­tion be­tween ques­tions where the an­swers are know­able and ques­tions where the an­swers are dis­cov­er­able. Know­able an­swers can be looked up: there’s an answer out there and you just have to find it. Dis­cov­er­able an­swers are ones you have to fig­ure out through pro­to­typ­ing and ex­per­i­men­ta­tion. This dif­fer­ence can help you direct a team’s re­search more pro­duc­tively — but you’ll need to make sure they ask both kinds of ques­tions.

Imag­ine for a sec­ond that you are in­ter­ested in cre­at­ing a new fi­nan­cial ser­vices of­fer­ing for young peo­ple, to help them es­tab­lish them­selves on a path to life­long fi­nan­cial well­ness. Fig­ure One shows some of the strate­gic ques­tions you could ask and whether they are mostly know­able, dis­cov­er­able, or an in­ter­est­ing hy­brid. The last col­umn shows how we might get more in­sight or ev­i­dence of the ‘right’ answer. It’s bet­ter to use pro­to­typ­ing to ac­cel­er­ate cus­tomer re­search and to test as­sump­tions quickly, so when­ever you see a hy­brid ques­tion, ex­pect to use low-fi­delity pro­to­types to ex­plore the answer.

As an in­no­va­tion leader, your job — first and fore­most — is to make progress.

In clos­ing

As an in­no­va­tion leader, your job, first and fore­most, is to make progress. That means help­ing your or­ga­ni­za­tion ex­pand its im­pact by bet­ter un­der­stand­ing and serv­ing its cus­tomers and launch­ing bet­ter prod­ucts and ser­vices that peo­ple value. Mak­ing progress on in­no­va­tion by em­brac­ing the prin­ci­ples out­lined herein will not only build cred­i­bil­ity for you and your team, it will lead to more sup­port and re­sources — con­tin­u­ing the cy­cle of progress.

Ryan Ja­coby is the au­thor of Mak­ing Progress: The 7 Re­spon­si­bil­i­ties of the In­no­va­tion Leader (Sense & Re­spond Press, 2017, www.sense­an­drespond­press.com), from which this ar­ti­cle is ex­cerpted. He is the founder of MA­CHINE, a strat­egy and in­no­va­tion com­pany based in Brook­lyn. Pre­vi­ously, he ran IDEO’S New York City of­fice and built its Busi­ness De­sign dis­ci­pline.

Newspapers in English

Newspapers from Canada

© PressReader. All rights reserved.