Author Archives for bobtaniguchi

Evangelize early? Worked for BB10

Another former ‘Softie Evangelist, Alex St. John is blogging about the DirectX days.  Lot’s of interesting ideas and history in his blog, but one topic caught my eye: Evangelize early.   I couldn’t agree more.  Alex talks about the DX team working with the game industry before anything in DX was really working, making it participatory and getting the game developers to invest long term by working along side the team on the same timeline release to release.  Great tactic if you can pull it off, and was in the Microsoft Evangelism Playbook for years.

This sounds pretty early doesn’t it?  Well, I’ve got an example that is even more extreme.  Believe it or not, I evangelized Windows NT for Microsoft when it was just a stack of papers.  I flew around the world with some of the leaders of the original Windows NT development team conducting design reviews of Windows NT *paper specs* with our key ISVs before any code was running, not even a demo.   Why? Remember at the time Windows was moving from 16 bit to 32 bit, adding real multitasking and virtual memory as well as the ability to implement protected subsystems running things like POSIX  compatible API shells.  We were interested in whether ISVs wanted Win32 to track the semantics of Win16, or could we “do the right thing”.  Pretty universally the answer was, do the right thing and don’t saddle us with a legacy design from Win16.  Whew, that’s exactly what we wanted to hear.

Doing things this early is quite risky, you tip your hand to the competition.  You may be in fact wasting your partners time if the product either doesn’t ship or is radically different in the end.  But in this case, it was warranted and we were rewarded with both early support and an architecture and an API pattern that served the industry for 20 years.

Our BlackBerry 10 evangelism effort implemented some of these best practices.  A full nine months before launch we provided more early seed units to the worldwide developer community than BlackBerry or anyone else in the mobile industry has before, to the best of my knowledge.  While we didn’t review paper specs, (that would have been at least a year before I joined the company), app developers did incrementally familiarize themselves with our early builds of BlackBerry 10, provided feedback along the way and ultimately rewarded us with an industry record level of early support for a new platform at launch.

When is the right time for you to begin evangelizing your product?

“So, how did you guys do it?”

The question of the week from non-DRG colleagues in BlackBerry as well as numerous new friends in the mobile industry is how did we launch BlackBerry 10 with the largest catalog of apps for a V1  platform?  Something no one knows is we also grew the *old* BlackBerryOS catalog 300% during the same time period.  It’s worth noting I don’t get this question from old Microsoft friends and you begin to realize the answer to this question.  Talk with any former ‘Softie of a certain era, and they’ll tell you about the “Evangelism Playbook”.  No, it’s not a real book, it’s a hard won set of strategy and tactics passed along in the organization.

There are now great blogs and websites like the “Developer Evangelism” site (Well done Chris Heilman! @codepo8) that cover the tactics of Evangelism, like use of social media tools, working barups & meetups and truth be told this constitutes a significant portion of the old  MS “playbook”.  However, with multiple OS platforms, PCs and different device offerings, server apps platforms, cloud app platforms… how do you cut through the noise and reach the developers that will take adoption of your platform or service to the next level?

In my experience fundamentally what makes an Evangelism team succeed or fail is not the number of hackathons or meetups attended, it’s building a culture of success  through empowerment.  Ok, I know this sounds a bit too Tony Robbins-esque for comfort, but I’ll explain.

Assuming you’re starting with the same set of tools, budget, staffing as the start up in your category located down the 101 from you, how do you differentiate?  In a funny way, it’s applying agile methodology to Evangelism.  View each campaign as a sprint, debrief & debug based on results, recalibrate and relaunch.  The “scrum” is really ideation, finding new solutions as a team, but, it’s always up to the evangelist on point to make the call.  In this case, each evangelist must control his or her fate via innovating fast, without fear of failure.  Simple to say, hard to do.   There was a period of time at MS where evangelism was managed very prescriptively, evangelists were tracked by a spreadsheet full of metrics, and surprise, MS lost enormous developer intent scoring during this period of time.  Folks on my teams will hear me say things like “always get better”, wow, what an insight Bob.  I’m really saying, “go try” and I’ve got your back.

For me this best practice stems from an old Microsoft product team project “post mortem”.  Before any product team launched design on their next release, Engineering, Test, Program Management, Marketing and Product Support would sit down and discuss what went well, what didn’t and together as a team they decided ultimately what to do next.  Takeaways were assigned to individual owners who were empowered to make decisions for the team, not in a vacuum,  but it was first and foremost their decision.  This was the secret of old Microsoft, empowered teams.

Does this work?  Yes.  Over the last year there are innumerable examples of the BlackBerry Developer Relations team taking an industry wide tool or tactic, and then quickly tweaking it to deliver unheard of results.  Very often the insight that changed everything didn’t come from the owner of the campaign, rather, another team member who felt empowered to provide the feedback and then worked with the owner to make the relaunched campaign a success.

Does this sound like your team?   If so, congratulations and I look forward to seeing your great ideas out in the Ecosystem.

NEW: Alec discusses reinventing Porting Labs as an example of rapid innovation:

In the beginning, BillG created the Evangelists in his own image

It was 1989 and Microsoft was facing down a daunting three pronged product strategy: first to continue evolving DOS, second to garner support for the nascent DOS based GUI environment named “Windows” and third building an entirely new operating system with then partner IBM called “OS/2”.  How can the company possibly deliver application software for all three operating systems?

Ever vigilant of competitors strategies and tactics, Microsoft noted the seeming success of Apple Computer’s “Evangelists”.  A team was quickly assembled to answer this Apple threat, and in what would be become a common Microsoft tactic, made the role it’s own by tweaking the title to “Technical Evangelist”.  This team was called the Microsoft Developer Relations Group and was Microsoft’s first evangelism team.  I was part of this team and the lessons we learned way back then continue to be applicable today.

From the beginning Microsoft’s Technical Evangelists were very different than Apple’s team.  First and foremost, we were all developers.  We had coded apps for Windows, Unix, workstations, mini and mainframe computers.  In contrast most of Apple’s Evangelists were MBAs and were non-technical.   Secondly, our evangelists were laser focused on helping partners deliver their code, gain distribution in the channel and market their products.  Apple Evangelists, in a weird bit of foreshadowing, delivered an “experience meeting” more like a big tent revival.  As the other Japanese American technology evangelist in the industry at that time, I was always hearing comparisons to Apple’s Guy Kawasaki.  Although he and I had the same goal, to lock up ISV platform investment, we employed very different tactics.  During these early days of evangelism I heard many times that “Guy was here last week…”  then “.. you guys are very different…” and most importantly that “… we’ve decided to do the Windows version of our app first”.

I’ve never forgotten this lesson.  Every Evangelism, Ecosystem and even Business Development teams I’ve built are made up of articulate, driven, technical, and entrepreneurial individuals.   My BlackBerry Developer Evangelism team is yet another example of hiring to this model.  Many of my current team have run their own startups and are already identified as industry luminaries in their area of specialization.  Ok, a few of them also have their MBAs, we try not to hold that against them.