Author Archives for bobtaniguchi

Focus, Focus, Focus on core value

In my Evangelism role I speak with developers and start ups all day, but when the start up is being run by an old friend, I listen carefully.  I’ve had the unique opportunity to observe my friends thoughts over a few years about developing a product or service based on his unique expertise and background over lunch or coffee.  During this time his thoughts evolved from a series of observations, to an idea, and now into a product that’s currently in development with a bunch of eager customers he and the team have already lined up.  What I’ve learned from him is another lesson of the power of focus.

Starting originally with observations of  classic  IT operational problems in big data centers,  my friend and his partners iterated through a bunch of product ideas, beginning with using streaming media and voice communications to monitor IT operations staff.  While doing this they came to a realization that they’d identified a powerful insight that’s driving their product’s core value: most problems they’d encountered are time based with location information and “who did what” being key data items.   Exactly the kind of information that a mobile phone can provide.

Turning a classic IT problem inside out, rather than using traditional data gathering  methods, they use the smartphone as the device that captures and encodes this information for their customers, turning what was a previously error prone and “after the fact” data collection problem into a real-time event creation captured using “point phone at thing (location, document, etc.), push button on UI, done”.  It’s a brilliant application of using the smartphone in a novel way.  By generalizing their observations after talking with a myriad of potential customers, they’ve actually moved to a different initial target market than IT operations.

He’s also applied some Evangelism principals we’ve discussed: like talking to customers early (evangelize early), he’s iterated rapidly on the core ideas (agile), he’s built a lean team (hire to your profile) and now he’s broadening the feedback loop (lunches with dudes like me…).

Looks like a success in progress, because the team is building an innovative product with a laser focus on maximizing via their core value.

iPhone prototype

Apple’s purported 2005 iPhone prototype

The interest in Apple’s reported iPhone prototype is understandable, folks hope to gain new insights into how Apple conceives of, designs and builds their products. My impression is that this system was a development system used to run and test early versions of the software, and indeed shows Apple’s thinking re: what became the iPhone platform definition.

Before, after and while at Microsoft I’ve worked on products that have bootstrapped on development systems that approximated the production units as much as possible, at times years before it’s intended launch. You select the processor/architecture family, memory footprint, I/O and make this prototype hardware platform definition as close to the silicon vendors projected availability of their new chip families in the supply chain at your release target date. You then design and build your OS software, drivers and any other hardware abstraction layers to target the core characteristics of the chip families selected. The more chip savvy of you will note this is why new processor features are often not exploited by the OS at initial release. So, indeed this system shows Apples selection of processor architecture and family, however, the screen used may have been a matter of convenience. It may not have been intended to be used at it’s full physical extent but probably was bounded by the target screen sizes Apple was testing. Also given the way the prototype is mounted on the stand it appears this setup was used to test input gestures as well.

So, how does this apply to the rest of the industry? Well, the good news is with off the shelf systems like Raspberry Pi readily available for intial prototyping, it’s an easy, low cost way for startups to prototype their ideas like Apple did using this custom engineered device. We’re seeing an explosion of new devices (not just smartphones) and new categories of devices being created daily for consumers and business. Many acquaintances and former colleagues of mine are now at start ups building devices who’s UI appears on a mobile device, the app is part of the overall solution and experience they’re building.

At BlackBerry we’re fortunate to have the experience of the QNX team who’ve worked on countless embedded implementations of their software. Together, we’re working to make the power of BlackBerry 10 and QNX available to build these new “solution devices” using the tools and platform we’ve shipped in BlackBerry 10.

Old School Rules!

Hal Berenson, former Microsoft Distinguished Engineer, writes an amazing  blog about his insights into past and present goings on at our former employer, but in this post he drills into what’s gone wrong with Windows 8 and Windows Phone 8 evangelism.  I have to say, I totally agree with Hal, the WP8 evangelism approach of Apple-like secrecy was plain wrong, and ignored all the hard won lessons of the MS Evangelism Playbook.

As one of Microsoft’s original Evangelists and co-originators of the PDC and founder of WinHEC, the former Windows software and hardware ecosystem conferences now defunct, sharing as much technical information as early as we could was instrumental to building support for each release of Windows I worked on. I talked about this in an earlier post, how evangelizing products early paid off for Microsoft and now BlackBerry.  Hal focuses on the feedback angle, realize at Microsoft we had smaller and NDA only feedback sessions sometimes years in advance of the PDC to fully brief and gather feedback from the ISV community.  These were the little known Microsoft Systems Design Review series and more granular feature level design reviews we convened with key technical leaders in the industry.

At BlackBerry being open and working with the app development community early as possible has already paid dividends for BlackBerry 10 with record early support.  We see no reason to change our approach, if the rest of the industry continues down the secrecy path, so be it.  I’m happy to run this key tool from the old evangelism playbook, time tested with proven efficacy.

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 critical, once 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?

Hardware Evangelism, yeah, you read that right

Something that I started at Microsoft was Hardware Ecosystem Managment, well, I always called it Hardware Evangelism.  Immediately following Windows 3.11 shipping, Microsoft recognized that PC’s at the time were too hard to configure.  A lot of people reading this post won’t have the faintest clue of what I’m talking about when I say you used to have to know about IRQ’s, DMA addresses and jumpers.  For the folks from the UK I’m not talking about sweaters.  I’m talking about all these things you needed to configure to add a new card to your PC, or connect a printer or attempt to add a new hard disk to  your system.  All these things were monstrously hard to do before Windows 95, USB and Bluetooth weren’t even things I could even have fantasized about.

So, what about applying Evangelism to….  hardware?  Well, many of the same principles applied.  Remember, there are things called device drivers that have to be written.  Firmware in ROMs need to be written to support new chipset features.  Protocols need to be understood by each subsystem of the operating system to discover, enable and configure new hardware devices.  So what did we do at Microsoft?  Well of course we created a conference, I of course creatively named it the “Windows Hardware Engineering Confernence” or as it became known in the industry, WinHEC.  We distributed Device Driver Development Kits, or DDKs.  We worked with standards bodies, industry groups, chip makers like Intel, companies who made motherboards,BIOS makers, third party chip set makers, display card vendors, harddrive vendors, the list goes on….

So all this information was published in a book called the “Hardware Design Guide for Windows ’95”, a description of all the new protocols, subsystems, interfaces and signaling that the Windows 95 kernel made available to implement the first implementation of Plug and Play on the PC.  This is what you know today, in most cases you just plug something into the PC and it just works, er, most of the time.  This book described the operating systems requirements to the PC hardware ecosystem to allow their devices to fully participate in Plug and Play.

To test these new Plug and Play devices with Windows our team hosted innumerable “Plug a thons” and for some devices “Connect a thons”, to be honest, after all these years I can’t remember what was different about the two events.   We created a new Logo Program and the “Windows Hardware Quality Lab” that managed the logo program and outside testing firms to certify both the new device drivers and the new hardware so consumers could easily identify Plug and Play enabled devices and PCs.

We even worked with the standalone chip foundries to insure runs of specialized chips were in the supply chain.

So why am I bringing this up?  Today many new startups are building devices that either interface to mobile devices via Bluetooth or WiFi, and solutions we pioneered with Plug and Play will be required to insure interoperability with each mobile platform as well insuring that your device plays well with other devices using the wireless connectivity.   In essence, some things never change, scenarios we worked through in the early ’90s for Windows are with us today, just in a different packaging and now wireless.  Which means right now there’s probably a Connect a thon running somewhere in the world….