Recommended
Recommended
More Related Content
What's hot
What's hot (20)
Viewers also liked
Viewers also liked (20)
Similar to How API became key to Whispir's growth strategy - Gartner AADI 2016
Similar to How API became key to Whispir's growth strategy - Gartner AADI 2016 (20)
Recently uploaded
Recently uploaded (20)
How API became key to Whispir's growth strategy - Gartner AADI 2016
- 1. Presented by: Jordan Walsh – Whispir Product Manager 26 July 2016 How APIs became key to Whispir’s growth strategy © Copyright 2000-2016 TIBCO Software Inc. #GartnerAADI @whispir @jordwalsh
- 2. About TIBCO TIBCO Software takes businesses to their digital destinations by interconnecting everything in real time and providing augmented intelligence for everyone, from business users to data scientists. This combination delivers faster answers, better decisions, and smarter actions. For nearly 20 years, thousands of businesses around the globe have relied on TIBCO technology to differentiate themselves through compelling customer experiences, optimized assets, and innovative new business models. © Copyright 2000-2016 TIBCO Software Inc.
- 3. © Copyright 2000-2016 TIBCO Software Inc. Growth Of APIs Continues 105 352 601 1116 1628 2647 4678 8000 10263 2000 2002 2003 2005 2006 2007 2008 2009 2010 2011 2012 2013 70% REST & Growing
- 4. © Copyright 2000-2016 TIBCO Software Inc. Businesses Are Paying Attention
- 5. © Copyright 2000-2016 TIBCO Software Inc. About me @jordwalsh jwalsh@whispir.com jordanwalsh23
- 6. © Copyright 2000-2016 TIBCO Software Inc. My API Challenges 1.Driving the Organisational Shift 2.Demonstrating value 3.Openness anxiety
- 7. The Whispir Platform © Copyright 2000-2016 TIBCO Software Inc.
- 8. © Copyright 2000-2016 TIBCO Software Inc. Whispir – digital communications, reimagined
- 9. © Copyright 2000-2016 TIBCO Software Inc. Whispir – inspiring action to achieve outcomes
- 10. © Copyright 2000-2016 TIBCO Software Inc. Whispir – use cases across a range of industries
- 11. © Copyright 2000-2016 TIBCO Software Inc. Whispir – API Program begins $2M Innovation Grant
- 12. © Copyright 2000-2016 TIBCO Software Inc. API Timeline 2012 2013 2014 2015 2016 Kickoff & MVP
- 13. © Copyright 2000-2016 TIBCO Software Inc. 1. Design, Build, Test (waterfall) 2. Engage an API management platform 3. Launch to existing customers Whispir – API implementation process
- 14. © Copyright 2000-2016 TIBCO Software Inc. Our requirements 1. Out of the box portal and live documentation 2. Speed to market 3. Back end service protection Whispir – API Management
- 15. © Copyright 2000-2016 TIBCO Software Inc. Launch and Growth • Our first API launch
- 16. © Copyright 2000-2016 TIBCO Software Inc. • First developer signup, 2 days after launch. • Over the next 4 months, expansion to ~10 developers. Launch and Growth
- 17. 2013 education and refinement © Copyright 2000-2016 TIBCO Software Inc.
- 18. © Copyright 2000-2016 TIBCO Software Inc. The goals for 2013 1. Complete API documentation 2. Whispir Education 3. Customer Growth & Product Refinement Education and Refinement
- 19. © Copyright 2000-2016 TIBCO Software Inc. Whispir – 2013 Daily API Usage (4 months after launch) 0 2000 4000 6000 8000 10000 12000
- 20. © Copyright 2000-2016 TIBCO Software Inc. API Timeline 2012 2013 2014 2015 2016 Kickoff & MVP ~5 active users ~300 calls per day Education & Refinement ~20 active users ~2500 calls per day
- 21. 2014 enable sales to be successful © Copyright 2000-2016 TIBCO Software Inc.
- 22. © Copyright 2000-2016 TIBCO Software Inc. The goals for 2014 1. Tools and Incentivisation 2. Create a Whispir `API Edition` 3. Find bigger customers Sales Enablement
- 23. © Copyright 2000-2016 TIBCO Software Inc. DevTools for Sales Enablement demo.whispir.com was born!
- 24. “without a doubt, [demo.whispir.com] enabled our team to more effectively discuss APIs with customers.” - Bradley Kendall, Senior Solutions Specialist © Copyright 2000-2016 TIBCO Software Inc.
- 25. © Copyright 2000-2016 TIBCO Software Inc. Create Whispir ‘API Edition’
- 26. © Copyright 2000-2016 TIBCO Software Inc. Developer API + User Platform = Customer Outcomes
- 27. © Copyright 2000-2016 TIBCO Software Inc. Whispir – 2014 Daily API Usage (16 months after launch) 0 10000 20000 30000 40000 50000 60000 70000 80000
- 28. © Copyright 2000-2016 TIBCO Software Inc. API Timeline 2012 2013 2014 2015 2016 MVP ~5 active users ~300 calls per day Education & Refinement ~20 active users ~2500 calls per day Sales Enablement ~180 active users ~30k calls per day
- 29. 2015 API is a product © Copyright 2000-2016 TIBCO Software Inc.
- 30. © Copyright 2000-2016 TIBCO Software Inc. The goals for 2015 1. Build a product team 2. Rebrand, Relaunch 3. Automated signup 4. Industry awareness Treat the API like a Product
- 31. © Copyright 2000-2016 TIBCO Software Inc. The birth of whispir.io
- 32. © Copyright 2000-2016 TIBCO Software Inc. Industry Events
- 33. © Copyright 2000-2016 TIBCO Software Inc. Whispir – 2015 Daily API Usage (2.5 years after launch) 0 50000 100000 150000 200000 250000
- 34. © Copyright 2000-2016 TIBCO Software Inc. API Timeline 2012 2013 2014 2015 2016 MVP ~5 active users ~300 calls per day Education & Refinement ~20 active users ~2500 calls per day Sales Enablement ~180 active users ~30k calls per day API Productisation ~420 active users ~65k calls per day
- 35. 2016 understand our target customer © Copyright 2000-2016 TIBCO Software Inc.
- 36. © Copyright 2000-2016 TIBCO Software Inc. The goals for 2016 1. Understand where the profitable markets are and focus on them. 2. Remove the self-registration capability. 3. Grow marketing and sales capabilities. 4. Build partnerships with SaaS vendors. Target our customer
- 37. © Copyright 2000-2016 TIBCO Software Inc. Whispir – 2016 Daily API Usage (3.5 years after launch) Jan 2013 Jan 2014 Jan 2015 Jan 2016 258242 June 16 0 50000 100000 150000 200000 250000 300000
- 38. © Copyright 2000-2016 TIBCO Software Inc. API Timeline 2012 2013 2014 2015 2016 MVP ~5 active users ~300 calls per day Education & Refinement ~20 active users ~2500 calls per day Sales Enablement ~180 active users ~30k calls per day API Productisation ~420 active users ~65k calls per day Understand the market ~291 active users ~250k calls per day
- 39. © Copyright 2000-2016 TIBCO Software Inc. API Timeline ~404,000 API Calls yesterday
- 40. What I’ve learned © Copyright 2000-2016 TIBCO Software Inc.
- 41. © Copyright 2000-2016 TIBCO Software Inc. • Utilise Strategic Services – Tibco Mashery • API is a product • Enable teams as early as possible • Understand your market • Deploy, nurture, iterate, deploy What I’ve Learned
- 42. © Copyright 2000-2016 TIBCO Software Inc. Questions?
Editor's Notes
- I’m Jordan Walsh, Product Manager at Whispir, and today I’m here to tell you my API story.
- First up, as this is a presentation on behalf of Tibco, let me just run through a couple of slides required by Tibco… (read text) NEXT SLIDE
- Firstly a bit about me: Been running the API program in Whispir for the past 4 years Story may be familiar Developer focused product Show of hands. Challenges NEXT SLIDE
- How do we get the organization on board? Stakeholders don’t understand the value Fear that our product will be used against us, How do we build, market, sell, and support this? We had all of these challenges and more. It took time, but we were able to overcome these to take our product to market which is now being used by hundreds of developers to solve business problems all over the world. So hopefully a few of you will get something out of this talk. NEXT SLIDE
- Whispir is a cloud based communications management platform that was founded in Melbourne in 2006 and has expanded to over 500 customers all around the world. At Whispir, we know that communications are fundamental to every business on the planet, and effective communications are what make businesses successful. So Whispir provides a platform that our customers use to ensure their communications with employees, customers and stakeholders are effective, every time. Starting with cross-channel messaging, response reporting and analytics, through to contact and distribution list management, Whispir has all of the tools required to effectively communicate within your business. NEXT SLIDE
- Effectively communicating.. What does that actually mean? At Whispir we understand that the way to determine if a communication has been effective or not is to understand the outcomes that have been achieved. If you’re asking someone to visit a website, did they do so? If you need to check their safety after an incident, did they respond? Only through analysing the outcomes can you understand if your communication had the intended effect. The Whispir method is to help you send the right information, to the right people, at the right time, over the right channel to ensure the outcomes can be achieved and ultimately, the business vision can be realised. This has been an extremely effective approach in a range of industries and use cases… NEXT SLIDE
- From Business Resilience Comms; emergency response, production updates, incident management, used by major airlines and banks in Australia and around the world, And Operational Comms; shift notifications, billing updates, used by utilities, public transportation and government departments, Through to Customer Engagement about new products and services use by some of the largest brands in the world. We know our model works. So naturally as a communications platform, it’s obvious that some sort of API connectivity to allow other systems to integrate with us would be a natural extension and growth model. Well this was where our API story started back in 2011. Next slide
- In 2011 Whispir received a grant from Commercialisation Australia. The purpose of this grant was to grow our ‘OpenWhispir’ initiative. We had a grand vision of a collaborative platform that allowed the use of open data to facilitate business decisions on top of the Whispir Platform. Fortunately for me, senior stakeholders from both business and technology understood that the first step in building this kind of open data platform was to create a mechanism for information to easily flow in and out of Whispir. Henceforth referred to as our ‘API’.
- Now, I had only been an employee of Whispir for around 12 months, so not really knowing how the design methodology for new products worked, I started with what I knew from my experience at IBM; write a big document. My macro design document was about 160 pages long. The OpenWhispir API Definition. Again, following my experience, the next stage was to get signoff.. So engineering, product, ops, finance, sales. Everyone was invited to provide feedback into the definition of the product. You can imagine how many responses I got back. My next step, involving engineering to review. Again, in hindsight, not exactly the right approach. So from January 2012 through to June 2012, we iterated over our API product to finalise a baseline set of features that we wanted to take to market. This was internally referred to as our MVP (Minimum Viable Product). About halfway through this process, we started investigating what API Management Software was, and what it meant in the context of taking an API to market. The main reasons we investigated this were: We wanted an out of the box developer portal for registration, and documentation We needed a solution for routing API calls to our different data centres We needed to ensure that our back end servers would be protected through rate limiting
- Now, I had only been an employee of Whispir for around 12 months, so not really knowing how the design methodology for new products worked, I started with what I knew from my experience at IBM; write a big document. My macro design document was about 160 pages long. The OpenWhispir API Definition. Again, following my experience, the next stage was to get signoff.. So engineering, product, ops, finance, sales. Everyone was invited to provide feedback into the definition of the product. You can imagine how many responses I got back. My next step, involving engineering to review. Again, in hindsight, not exactly the right approach. So from January 2012 through to June 2012, we iterated over our API product to finalise a baseline set of features that we wanted to take to market. This was internally referred to as our MVP (Minimum Viable Product). About halfway through this process, we started investigating what API Management Software was, and what it meant in the context of taking an API to market. The main reasons we investigated this were: We wanted an out of the box developer portal for registration, and documentation We needed a solution for routing API calls to our different data centres We needed to ensure that our back end servers would be protected through rate limiting
- Product Launched. We did also send an email to our customers to advise them that the API would be available to existing customers from October 22nd. We didn’t really have a solution for new customers at this stage. The goal was to onboard some existing customers and see what we could get done. This was the right approach for us at the time (just dipping our toes).
- Our first customer on the API came through an off-hand conversation with one of our sales team. He didn’t really know what the API could do (we hadn’t trained them yet), but he had heard that one of his customers was looking for an automated notifications solution, so naturally I jumped on it. I ended up working really closely with this guy who became a fantastic source of guidance for how to write our initial documentation. What started out as a series of emails of me advising him how to do things became the basis for our first version of the documentation. He was up and running on the API within a few days, and had launched his automated notifications solution sorted. I continued writing the documentation and iterating with him, closely monitoring his progress and making sure he didn’t have any issues. The service was chugging along sending a few SMS until the end of November when their internal systems had an outage. Their solution kicked in and notified 173 people within a few seconds of what was happening. This was the first real time that our API had been used in anger, and it was fantastic to see it working as expected.
- Due to the open nature of the API, and the very few assumptions we made about how users would actually code against us, the model that we were left with was something that each customer could take and integrate with however they chose. In 2014 we saw just how possible it was that the Whispir API could run as a product in it’s own right. So we did exactly that. Treat our API like a product.. Remember that lesson from back at the start, it took us 2.5 years to put this into practice.
- In this time our usage went up from around 300 calls per day, to around 2500 calls per day. This is a growth of around 733% or 61% month on month growth. Again, not game changing, but ok.
- Due to the open nature of the API, and the very few assumptions we made about how users would actually code against us, the model that we were left with was something that each customer could take and integrate with however they chose. In 2014 we saw just how possible it was that the Whispir API could run as a product in it’s own right. So we did exactly that. Treat our API like a product.. Remember that lesson from back at the start, it took us 2.5 years to put this into practice.
- During this time we managed to onboard a few more customers and by the end of December 2012 we had 10 customers who were either using us actively, or experimenting with some application ideas. Not exactly the killer growth everyone desires, but hey, we hadn’t done any marketing, a proper launch, nor was the documentation ready for prime time. In 2013 we made more of an effort to complete the documentation and also arm our sales team to go out and talk about this stuff. Just because it’s API doesn’t mean they can’t discuss it. I built a service called demo.whispir.com. The goal of this service was to allow a salesperson to demo the API by sending a message using a simple web interface, and it showed the code required to execute this right on the screen. We had implemented io-docs by this stage, but the sales guys still thought this was too techy, and wanted something they could interact with a bit easier. This tool became used so widely, that it was getting hits from New Zealand, Australia, Singapore and the UK to sell Whispir.
- The sales team loved this so much, that we actually increased the number of use cases that we were demoing. They were now asking our development team to build stuff that could live here because it was so easy to demo to customers. This sales enablement lead to the only natural outcome, more customers. By the end of 2013 we had around 25 active developers in our community. Doesn’t seem like much, but two of these customers were sending 100% of their traffic through our API. They had no reason to log into our console anymore because their entire use case could be met through our API only. This epiphany was quite strong. We can sell just our API. We don’t need to sell the whole sausage factory, we can just sell sausages. We created a new edition of Whispir called the ‘Whispir API edition’. This gave customers a low cost route to getting only access to our API when the full platform was not required.
- 2014 was the year that we also started to get some proper names using our products. From airlines, through to postal services, healthcare, recruitment, customer parking offers. All sorts of use cases were popping up. The other thing was this was the year that the API became critical in a number of very large deals for Whispir. These deals we wouldn’t have even been at the table on if we didn’t have a documented API that we could offer.
- In 2014 the growth continued (remember I was still the only person looking after the API during this time…). This was the year that the API really started to hit it’s straps. We started at around 2500 per day, and by the end of the 2014 we were up to closer to 30,000 API calls per day with 180 active developers. Around 1100% growth or 91% month on month.
- Due to the open nature of the API, and the very few assumptions we made about how users would actually code against us, the model that we were left with was something that each customer could take and integrate with however they chose. In 2014 we saw just how possible it was that the Whispir API could run as a product in it’s own right. So we did exactly that. Treat our API like a product.. Remember that lesson from back at the start, it took us 2.5 years to put this into practice.
- In 2015 we hired my former colleague Anthony Russell. He came on board as the Director of Whispir.io, a new face and brand to the Whispir API. The mandate was to update the developer portal we hadn’t touched since launch 2.5 years prior, enable a self-signup process to onboard people quickly, create a developer relations strategy, and a third-party plugin strategy. Our first step was to rebrand. It took a few months by by April 2015 (just in time for the Sydney AWS summit) whispir.io had launched! We even sent a tweet.. We did a better job of launching this one (not that the tweet shows it).. We did a roadshow with AWS from Sydney through Singapore and to KL. We took it to our channel partner Telstra and worked with our marketing team to launch a proper email marketing campaign. By the end of 2015 we were up to around 420 active developers, making around 65.000 API calls per day. Only up 116% this time..
- In 2015 we hired my former colleague Anthony Russell. He came on board as the Director of Whispir.io, a new face and brand to the Whispir API. The mandate was to update the developer portal we hadn’t touched since launch 2.5 years prior, enable a self-signup process to onboard people quickly, create a developer relations strategy, and a third-party plugin strategy. Our first step was to rebrand. It took a few months by by April 2015 (just in time for the Sydney AWS summit) whispir.io had launched! We even sent a tweet.. We did a better job of launching this one (not that the tweet shows it).. We did a roadshow with AWS from Sydney through Singapore and to KL. We took it to our channel partner Telstra and worked with our marketing team to launch a proper email marketing campaign. By the end of 2015 we were up to around 420 active developers, making around 65.000 API calls per day. Only up 116% this time..
- By the end of 2015 we were up to around 420 active developers, making around 65.000 API calls per day. Only up 116% this time.. I learned that the bulk of this API traffic (around 70%) was coming from less than 20 developers. There were a lot of people signing up for the API, making a few requests then bouncing away, not too many hanging around and integrating into their applications.. I found this surprising. We spent a lot of effort in creating a new portal and documentation environment for these customers to have a seamless signup experience. But all this allowed for was us getting more developers through the door, not so many converted customers. Whether we could have done a better job nurturing leads or what have you, i’m not sure, but in any case, the self-sign up wasn’t producing the conversions we had hoped and the amount of garbage coming through was too much, so we disabled it.
- Due to the open nature of the API, and the very few assumptions we made about how users would actually code against us, the model that we were left with was something that each customer could take and integrate with however they chose. In 2014 we saw just how possible it was that the Whispir API could run as a product in it’s own right. So we did exactly that. Treat our API like a product.. Remember that lesson from back at the start, it took us 2.5 years to put this into practice.
- The number of active developers in 2016 thus far is 291. That’s a decrease of around 30%, however the API calls are something different. When i checked this morning we were sitting at 375,000 API calls yesterday. From the start of the year this is an increase of 477%, or around 80% month on month growth. By the way.. All of the statistics for this presentation were pulled directly from the Tibco Mashery console.
- Due to the open nature of the API, and the very few assumptions we made about how users would actually code against us, the model that we were left with was something that each customer could take and integrate with however they chose. In 2014 we saw just how possible it was that the Whispir API could run as a product in it’s own right. So we did exactly that. Treat our API like a product.. Remember that lesson from back at the start, it took us 2.5 years to put this into practice.
- Products need customers – go and find someone who actually needs what you’re building! Group the identified use cases and use this as the baseline for what should be delivered. Mock an API using your favourite mock tool (Swagger/RAML/io-docs) Distribute the mock to potential users for feedback Integrate feedback -> Build -> Iterate API Management is a strategic solution, not a software solution. Tibco/Mashery launch APIs with customers every day, so learning from them could have saved me and my team a lot of time. It took a good 2 years for our API to become known amongst even our own customer base. We did a terrible job of marketing it. Understanding our target market would have helped us focus earlier, and also built out a marketing plan to ensure they were aware of our tech.