Evangelism question time #1

First, thank you for all your comments, feedback and questions.  I’ve really enjoyed hearing from old industry colleagues and new friends in DevRel roles around the world.  Thought I’d share some questions we’ve discussed that I think are of general interest in a round up post.

We don’t have the resources to build an Evangelism team like BlackBerry’s, can I hire a Community Manager to run my developer program?

Well, maybe.  Developers can spot other developers in a heartbeat, they can also spot someone that’s not a developer  just as quickly.  If your community manager is a developer and has participation from your Product Development Team, this may work but I’m assuming that you’ve built out an SDK, developer portal, blog, forums (yours or Stackoverflow and their ilk), Twitter and Facebook presence as prerequisites.  Your team needs to build a thoughtful and targeted key influencer program to help you scale out your message.  Evangelism is active and participatory, so, you should build a company wide understanding of your engagement model because everyone is an evangelist.

What about breadth vs. depth programs?

The funny thing about this, I get a lot of pings from former ‘Softies on this one.   This question is a classic “can I have my cake and eat it too?” resource investment problem.  Simple answer, I didn’t find the silver bullet at BlackBerry,  we bit the bullet and did both to the best of our abilities and resources.  Mind you, BlackBerry took ecosystem building seriously and invested on the order of a 10X increase in investment over anything RIM had done before but still pales in comparison to investment levels at my former employer.

Should we charge for our Developer Program?

We decided that information and SDKs should be free, however “App Certification” is paid (our Built for BlackBerry program).  I believe the time to “Hello World” is criticalonce you’ve captured a developer’s attention, so for BlackBerry we’ve focused on speeding and simplifying our programs as much as possible and still have more work to do here.

Come on, your other posts about what tactics and strategies you used are the same as everyone else, where’s the secret sauce?

Well, really there is no secret sauce, perhaps a quick summary will help.  Your single most critical success factor are the people on your team, they have to all be great hires.  All my Evangelists must be interviewed by me and Alec and have the key skills, background and “intangibles” we’ve seen in our high powered Evangelists.  Next is consistency, both in your approach on engagement, but your product design must manifest what you’re evangelizing to the community in terms of value prop and experience.  Does your firm  believe your ecosystem is strategically key to it’s success?  Believe me this commitment, or lack thereof shows through to developers and won’t invest if they feel you’re making a temporary investment.  Be approachable, the “anonymous evangelist on a forum” persona is a recipe for failure, people respond to people.  Yes, we’re in the technology business but Evangelism is a People business, it really is about hearts and minds.  Have fun, take risks and be memorable.

What do you think of what “fill in competitor name here” is doing with their Evangelism program?

Most often I get asked about my former employer, and the honest answer is I don’t know and you’ll have to do the research and form your own opinion.  If you’re asking me to benchmark what we do vs. others, something I learned at my former employer and my read of the Steve Jobs biography is that Apple also observes, adopts and “owns” strategies and tactics we all see in play developed by others in the industry.  You should too.


Fun with statistics

In the run up to our launch in the USA, I suspect discussion of  the number of Android titles in BlackBerry World will again surface.  First a bit of history to frame my thoughts here.

Historically platform changes have always been a high risk/reward proposition, and the industry continues to exhibit behavior described by Geoffrey Moore in his classic Crossing the Chasm.   Using Moore’s terms, to encourage  “pragmatists” to adopt lead to creation of a  two part platform introduction strategy.  First, focus all evangelism on the new platform to attract the “early adopters” and secondly supply tools or a porting layer to enable a move from the incumbent platform to the new target to decrease risk for the “pragmatists”.

Does this work?  Yes, over the many platform changes I’ve overseen on the PC use of porting tools/layers have been effective tactic, but I’ve not seen as an effective implementation and execution as we’ve done at BlackBerry.  While the speculated number of Android ported apps in BlackBerry World grossly overshoots the actual numbers, what’s important is the number of “pragmatist” partners who used the porting layer to ship a BlackBerry 10 app for launch with minimal risk.  Based on observed BB10 results/downloads these partners are now working on native BlackBerry 10 Cascades apps that fully integrate with the BlackBerry Hub, for them, the porting layer served it’s purpose.  This is a textbook example of the platform change strategy in execution and over the coming months we’ll all enjoy this second wave of  native BlackBerry 10 apps.

Every year, we’re getting… younger?

At BlackBerry Jam Europe, I was asked what was surprising to me about working with the BlackBerry developer community over the last year; and I replied how rapidly the average age of developers is decreasing.  This observation is supported by both market research sources, and what I have observed first hand.

Last summer on the BlackBerry Jam World Tour, part of the event was a “lightning pitch” contest.  We usually had ten to twelve developers participate; they had five minutes to demo and pitch their app to the crowd.  What was notable is that the youngest winner of a lightning round was sixteen years old!  The youngest “pitcher” that participated was 13!  There were many exceptional young people who competed, all of whom had demonstrated advanced programming skills, and were not afraid to speak in front of audiences of several hundred people.

At our events I speak with college students who have already published multiple apps on multiple platforms.  What’s fascinating is the degree of sophistication they possess; they tell me about analyzing download and sales data and how that lead them to localize their apps to better target other countries.  Others instrument their code to see what their customers are really doing with their apps.  I had a group this week walk me through all the different business models they’ve tried with their apps, from free w/ads to paid and even in app purchase and how they’ve optimized the revenue potential of their apps, this is phenomenal.

I always leave our events inspired by the passion and creativity of the developers I meet.  But these young developers who have developed such great technical and business skills so young, I can’t wait to see what they are going to do next.

Anatomy of a developer mind share turnaround

Today at BlackBerry Jam Europe 2013, my boss Alec Saunders (VP BlackBerry Ecosystems) announced that several leading developer research firms have reported a 28% to 38% developer primary target of BlackBerry 10.  To understand the magnitude of this reversal of fortune one must realize that during January 2012 NPS reports showed a developer sentiment of -40 for BlackBerry overall, so we achieved this turnaround during a single year with highly charged events occurring like the CEO changeover, network and financial issues.

I’ve previously discussed how operationally we quickly innovated on various well known evangelism tactics as a team and how that both focuses and unifies the team.   This also enabled us to try different tactics and strategies running simultaneously.  However, to achieve the developer mind share turnaround we need to take a year long look back.

First: While our team monitors and highly values third party research,  nothing beats actually talking to developers yourself.  Research inherently lags actual developer mindshare, our entire team “talks” to developers face to face and via popular forums constantly.  As I’ve always said, developers will tell you what they want, you just need to listen, then act, quickly.

Second: Consistency of strategy and message.  This must be based on real capabilities of your platform and tools.  While we’ve refined our developer message to “Beautiful, Integrated & Social” we started the year with a bit wordier and more conceptual version of the same messaging.   Your SDK must enable your developers to embrace and implement the key features and technologies that make your message a reality, they quickly dismiss any “marketing only” platforms.

Third: Live your own value prop.  Your own apps or features need to consistently manifest the same qualities that you are messaging to the developers.  At my old employers this was called “dogfooding”.

Fourth: Early access.  I’ve already talked about early evangelism in a previous post.

Fifth: Have fun!  Alec, Marty and Chris made the now infamous rock videos to just have fun with our developer community.  This is the true ethos of our approach to evangelism, to enjoy working with the community and share the love.

One last thing, read an analysts take on our approach to developers that he witnessed at our European conference today, said it better than I am able to.

Where o where are my mobile developers?

As I pack to go to our BlackBerry Jam Europe, I’m reminded that there’s always a debate over how many developers there are in the world.   I’ve seen over the years refinements of developer trackers and developer census, I’m not going to begin to try to slice and dice that data in this post.  But, this counting gets even more controversial when you begin filtering for categories, like maybe mobile developers?

So, I have an interesting different set of metrics to share.  To meet with developers where they live, over the last year I traveled literally around the globe.  Several times over.  In addition, my  BlackBerry evangelism team (not just me…) logged 2.5 million miles.  And if you consider that I have my team spread out home based in 19 tech centers around the globe, and we did 44 developer conferences in over 30 countries you may think I have it covered.  Last year when I started at BlackBerry, this is exactly what I would have believed.

For completeness, what’s the number of countries in the world? The Internet tells me that the UN has 192 members and that the US State Department recognizes 194.  So what percentage of these countries has a developer that’s submitted an app for BlackBerry 10?  10% maybe?  That’s close to the number of countries my team reside in.  Being generous, maybe as high as 20%?

The actual number is 55%!   We have seen apps submitted from 106 countries from around the world.  Analysts have claimed that all our apps are all coming from former BBOS developers.  Not true, at launch we already have much broader global developer support for BlackBerry 10 than BBOS.

Everywhere I go, I meet with Government and University officials.  Countries big and small are all investing in Computer Science curriculum, and this is confirmation that it’s working.   Mobile software development is truly a global phenomenon.  Opportunity calls. Are you ready?

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: