[MUSIC PLAYING] BALA KASIVISWANATHAN:
Hello, everyone. Good afternoon. My name is Bala And welcome
to day two of the breakout sessions. We have a very
interesting topic today. We're going to see
the intersection of what does product
management mean for APIs, some similarities
of what you would do, and what are some of the things
which are unique to APIs? But before I get into the
session, a show of hands, how many of you here actually
do product management as a job function? OK. Good. It looks like about 30%, 40%. So what we are going to do
in the session today is going to be, we'll just walked
through some framing of what product management does. What are some of the challenges
or uniqueness around on APIs? And then, we were very excited. We have, actually, one of our
customers of Appigee and Google Cloud, Pitney Bowes, here. And we're going to have
Jon Spinney kind of talk about the practice product
management for their APIs. And then, hopefully,
we'll have some time for question and answer. So that's the plan. So let's start with the
very basic question, what is product management? And I thought I'll ask
the tool we all know, which is, what does Google say? So Google came up with a
definition, which probably is very accurate in some sense. But it's probably not very
pragmatic for all the product managers in the room here. They read this and
go, hm, I really don't know whether I agree
with whatever that's saying. And depending on the day
you ask the product manager, they will describe their role
as this, or all of these, or some of these, depending
on what's happening on that particular day. And all my product manager
brothers and sisters here would agree
that this is how they feel, depending on the day. And I left out some of the other
things you might feel here. Because it's not
appropriate on the slide. But you all know what
I mean by this, right? So this is where
product management is, in terms of what
you do for any product you might be
managing, whether it's a technical product, hardware
product, or software product. So if you leave these
definitions out, and step back for a minute, and
think about, what is it that we're trying to do? It effectively boils down
to thinking about the user. And depending on
the product, it is all about, who is the
actual user of your product? And how do you really
focus all your energy? And when I say
all your energy, I mean you and the team
with which you're working to produce the
product to focus on that user. In some cases, it's
bigger than the user. It is the customer. And that applies to certain
segments of products. And in the case of APIs,
it's not just the customer. But it's also the developer. And that's what we start with
when we think about product management for APIs. So for us, the starting
point, or the constituent, who is most important when it
comes to product management for APIs is the developer. Now as you all know, when it
comes to product management, there are three kind of
big aspects out here. One is the customer, user,
whatever you want to call it, depending on your audience. The second aspect
is the technology. And the third one
is the business. You, as a product
manager, are trying to get these three to work in
favor, so that you can drive growth, drive success,
drive adoption, whatever the metric you care deeply about
for the success of the mission you're on. But if we really distill
down these three things into what exactly you
are trying to achieve for each one of
these constituents, it boils down to
delighting the customer, driving innovation
with technology, and last, but not the least,
driving business impact. That's it. And you can measure
this 100 different ways based on your business,
the metrics you can track, metrics you can't track,
the instrumentation you have in the product, or not. But at the end of the day,
if you don't have a delighted user or a customer,
and if you're not able to deliver very good
technical insight and unique value proposition for your
customers using technology, and last but not the
least, if you're not able to drive actual
impact for your business, it doesn't matter. As a product
manager, we all fail if those things don't happen. And it's kind of on us. And the kind of
good news/bad news here is we are kind of
accountable for this. That's the good news. The bad news is, you may not
have all the responsibility, or you may not have all
the empowerment you need or sometimes get through this. And that's what makes all the
product management jobs very interesting, and challenging
if you're up for it. So when we think
about APIs, how do we frame this delight,
innovation and impact in a different way for APIs? Well, we start with the notion
of actually the digital value chain. And some of who attended the
previous sessions, either where we talked about Apigee
products, or otherwise, have seen this time and again. And the reason we keep
using this framework is it actually drives home the
point of what we care deeply about when it comes to APIs. And it distills
the point of view that who the audience or the
user for your products is. If your product is the API,
the user is your developer. So this evaluation makes that
point very, very clear to you. And the good news here is, when
you're thinking about the API, depending on where you are-- either you are providing the
product for the API product team, or the API
team in this case, or it's the consuming
developer who is on the right side
on the screen for you. That person, or
that user, defines what is success looking
like for your APIs. Now whenever I talk about
the API and the developer being the user, we
also go with the notion that the APIs are, effectively,
your company's contract with the developer. But it expands from there. Because the API itself can
be used in multiple ways. So lets look at the
three typical ways we think about APIs when
it comes to that contract. Number one is what we
call API as a service. And this is very important
in a large organization. And some of you
probably attended one of my colleague's
session, [INAUDIBLE], who talked about the
overall API-first approach in distributed computing. This is the premise for a
lot of the modern application development today,
where APIs the service that you're providing. And the reason you're
providing that is you have developers, who
you're not going to meet, and who would use your service,
and consume it via the API, and build something interesting. And you need to make sure that
they have the most frictionless way to build things,
and they are only seeing it as a service. And for them, it's they
consume that service, build something, and move on. And you're going to make sure
that their life is really easy when it comes to
providing that API, making it easy for them to
discover it, making it easy for them to access it. And the more people
in the organization build the APIs as a service,
the overall organization can move forward in
whatever innovation they want to do with the
least amount of friction. And this is something
we are starting to see even more now that modern
application development is happening. Micro services is taking off. People are doing
interesting workloads and building containerized
applications. This becomes even
more important. Because you want this kind
of flourishing innovation to happen when people are
using API as a service. Now in this, you can
almost take the view that your internal
developers, your own teams, are the customers. And this is a kind of slightly
harder shift for a lot of enterprise, especially. Because they are so used to
having one-on-one integration, or one-on-one agreement within
teams to build something-- which can be, sometimes,
very brittle-- to go from there to something,
which is much more scalable when it comes to an
API as a service. But once you have this, then
you are ready for the next step. And the next step is what we
call as APIs as interaction. But show of hands, for
example, how many of you use YouTube or Netflix
for viewing content? Most of you, right? Now the good news
is that you probably are viewing that content in
different devices all the time, on the laptop, on your
mobile device, on an Xbox, on a Chromecast. Every very different
device, you're watching the same content and
interacting with that content. And we have seen
people use the API as what we call
Expediency APIs to improve that part of interaction. And Netflix, at some point,
really did this well, where they would have, actually,
APIs based on the device, or based on how you're
consuming the actual content, the experience would change. And that doesn't mean that
they going and rewriting a bunch of applications or
APIs, which are being used to expose some of the services. But they actually
change the APIs on the consumption
side, which is purely to drive the
differential experience, and create the right interaction
for you on the right device. And that's how you're able
to scale to over 300 devices, for example, in
their case, and still have the right level
of interaction, and right level of experience
for you, as a consumer, when it comes to that service. Now for that to happen, somebody
had to think about the API as an experience or
an interaction API. And that was the product. And if that product
was not there, the developer would
not be able to deliver the interaction
or the experience you actually were so
familiar with when you click Play, and watch something. And you felt like,
wow, this is so good. And you didn't care
about whether the device was a tablet, or a
phone, or a laptop. And that's what happened when
somebody was able to deliver APIs as interactions for you. So that's kind of
this on second level. The third level is where we take
this one notch up, and actually really think about
APIs as products. So the notion of
products immediately kind of brings a
very specific image in your head, which is that
means there is a packaging. There is something
around pricing. And there is something
that on how you actually deliver this to people. And these are the aspects
Jon is going to talk later. But at the core of
this is, effectively, how do you start to think
about APIs as a product? Now if you think about
APIs as a product, then each one of you who are
playing a product manager role for whatever
product you're doing, you have to start
thinking about even these APIs as your products. So let's say, for example, one
of you in the audience here has a software product. And I meet a lot of
customers who have, actually, a software product. And they're trying to build
an ecosystem around it. So the one set of PMs are really
driving the product itself. And so how do we
deliver the product, and our users can use it? And then we measure, improve,
and drive the business impact. Awesome. There's a set of PMs, then,
who are thinking about, how do I take this and deliver
value with my partners? And for them to do interesting
integration, and experiences, and interactions, the only thing
this PM has to offer is an API. That's the starting point. So now if I'm an
ecosystem PM, and if I'm doing something
interesting with a partner, and I'm building
some interactions, I have to start treating
the API as my product. What does that mean? So first and foremost it has
to be a first-class citizen in your product portfolio. So why do I say that? It cannot be, well,
we have a product. You were trying to
run a partner program. Let's figure out, OK, we'll
come up with some API. No, you've got to treat that
API as a first-class product, as if, if your
systems went down, and a customer is
going to scream, you have to apply the same
rigor when the API goes down, and your partner is
going to actually fail in delivering something. So you have to treat it
with that level of care. But before even you get
to delivering that API with that level of care, you
have to start with the notion that, we need a great API. And if that API has
to be great, what are the characteristics for that? Why should the
developer use that API? What is unique about that API? How would I go and make
this API really frictionless for a developer? Those are the kind of things you
got to think about before you actually have any API. Now here's an interesting piece. For all the good software
products out there, hopefully there is
an API already used to build that product. And then the question
is, how do you really make that available
to somebody outside for certain functionality, or
certain aspects of the product, which can be used
for integration or doing some ecosystem work? But if you don't
have that API, you've got to go back, and figure out,
how do you create that API? But thinking about it
more like a product, as in you're
looking at the user, you're thinking about
their requirements. What do they need? What is the service level
you need to provide for them? And then, more importantly,
how do I deliver this to them in a frictionless manner? So that's kind of the starting
point of creating that API and delivering it
to your developers. The second one is, once you
have that API, it is not done. Because like any other software
product, or any other product you product manage,
you're constantly learning and you're improving. That means you're
looking at data. You're looking at feedback. And you're figuring out,
where are the bottlenecks? Where could we do
interesting things with this particular API? And what can I do better,
so that my partner, or my ecosystem folks,
can do something more interesting going
forward, and innovate on top of my product? So that comes to really
thinking about instrumentation, measurement, and
refinement as you go with the release of the API. So this is what we call-- it's not the launch of the API. It is almost thinking about
the lifecycle of the API, so that you're measuring,
looking at the data, and improving what
needs to happen with that particular API. The third one is, of
course, the impact piece, which is that it's all great. You have an API. You have a good way
to learn and improve. You're probably on to
version 3 of the API. So you went from kind of a
beta program, to a proper GA, and now you're in
version 3, which should be the most mature way
for people to actually access your systems of software, and
build something interesting. But the third one is impact. Is that particular
API really driving any value and impact for
you, and your customers, more importantly? Because remember, if
you have a product which has both the software
product and an API, you're looking at
two sides of the coin when it comes to a business. You can keep selling
more software, and/or you can also drive
information and experience through your APIs. And that can actually accrue
benefit back into the product. Or both can go independently. And they suddenly become
two streams of businesses. These all depend on
what you're doing, and what area, or what domain
you are in, and how it happens. But the end of the day, that
has to be an impact measurement. And this impact measurement
can be sometimes very fuzzy. Because you can start
with the premise that I'm going to
generate a lot of revenue from this particular API. So I have customers who
always come and say, we have a core business. That's growing very well. We're happy with that. We want to do this API
program, because we want to unlock a whole
new set of revenue. That's great. But the challenge is
the API itself does not generate revenue. You've got to invest in it,
like you do for any other go to market. Because now, you have
API as a product. How are you going to
take it to market? Who are your customers? How are you going to make sure
there's a demand for that? How are you going to make sure
there's awareness for that? How are you going
to convert that? How are you going
to then monetize that API to drive revenue
if that's the goal you have? So that's one of the things
you've got to think through, is when you think about impact,
you're also thinking about, how do I take this API to
market to drive that impact? The second notion is that you
have no revenue attachment whatsoever to this API. But it's a fantastic way to
build loyalty and stickiness to the platform. And we've seen
examples of this over and over again, whether you take
a very simple example like what Slack does today, or
Google Maps API does today, is that the API itself may or
may not generate the revenue. But the integration
it allows you to do, the experience it creates, makes
people keep using the product. And that is gold. Because at the end of
the day, what you want is people to continue to
use your core product. And the API has become a way to
kind of find out, if you may, and bring in more audiences,
and bring in more partners who can build stuff on it. And when you really get to the
scale where a lot of people are building on top
of your product, and that's when you can
really start to think about yourself as a platform. And that gets
really interesting. And then you really don't
care about monetizing one particular aspect. Because now you have,
suddenly, a lot of opportunity to think about monetization
in a very different way. So the core of this, when
you think about API products, it goes back to
those three things. Number one, you've got to
treat this as a product. And that means you've
got to pay attention to, what are you delivering in
the unique value proposition to a customer, or a user of
that particular product, which is your API? Number two, you got to
think about how you're going to constantly
learn, look at the data, keep improving, and then
waiting on top of that. So you don't stop as soon as
you release the first version of the API, just
like you wouldn't stop releasing your first
version of software, or one model of a car, or
one model of a [INAUDIBLE] good product, or one particular
SKU [INAUDIBLE] or anything else. You're going to constantly
look at the data, and improve, and move
forward from there. And the last one is
really think about it in terms of, what is the real
impact measurement out here? Are you measuring revenue? Are you measuring the value
back to your core product? And how do you
nurture that, and not imagine that just because
you have an API, suddenly, things are going to
magically appear? It takes a lot of effort to
take that API, as a product, to the market, just like
you spent a lot of energy taking something
else to the market, in terms of your product. So when you think about those
aspects, that's where we really think about, we have
to treat the API as a product in this new
economy, our digital economy, if I can say that. And that's where a lot of
you, as a product manager, especially if you're
looking at anything which has remotely to do
with technology, you've got to think
about having an API. You also have to think about
even other products which can have APIs. I mean, we have
customers who do anything from financial transaction,
to logistics, to data, to sometimes even IOT devices. All of these things have APIs. And they're trying to
build something around it. And API has become
a way, or means, to deliver that value
differently to different users. And some of them do it
in a platform sense. Some of them do it
in the product sense. Some of them do it interaction,
or in terms of services. So hopefully, I've given you
a very basic but important framework to think
through how you can go from API as a service,
to API for interactions, to API as a product. And what are some of the key
principles around building APIs as products? Now that's a framework. That's a good theoretical
framework for all of you to have in your head. But it's always fun
when you have somebody who is practicing
this, and they can share what they have
learned, and how they think about this in real life. So to do that, I'm
going to welcome Jon. Jon Spinney heads up API
products for Pitney Bowes. And he's going to come and
share some of his learning. Please welcome Jon. JON SPINNEY: Thanks,
appreciate it. That was fantastic, in terms
of those three pillars. So I'm Jon Spinney
from Pitney Bowes. A little bit about us, we're
almost 100-year-old company. And we work across a variety
of different lines of business. We do identity management,
location, things like that. We process a lot of
transactions on a daily basis, billions across what we call a
borderless world of commerce. You know, I sometimes
think about the role a lot, and spend an inordinate amount
of time thinking about it. And an API in and of itself
is, I kind think of it as like an access
method to things that we have, and have
had for a long time. And one of the comments that's
really resonated with me, especially at this
conference, has been the transition
from we're in the midst of lifting and shifting. We've had customers
for a long time that have been using
products, that have had APIs available from them. And they can latch
onto those things. But we started a digital
transformation journey a couple of years
ago where we wanted to introduce APIs as products
available as a service. And that was a new
thing for the company. And we encountered all
of the typical challenges that someone going through a
digital transformation shift goes through. And I, sometimes, think
of introducing these kinds of products as the other 80%. Once you have the API, what is
all the other 80% of the things that you have to do in order to
operationalize it and turn it into a product? And I'll talk about some of
those things here in a second. So when we started
looking at how we would do this to help an
existing incumbent customer base, as well as go out and find
net new customers to consume APIs. To Bala's point, we put people
first, customers, users. But by people I
mean, ultimately, the people who are going
to, either use these APIs, or their partners in
business or finance who are helping them purchase
and bring in these APIs into their organization. But we've had folks
in telecommunications, and insurance, and
financial services, and other industries
use our software that's been on premise for
years, and years, and years. And there have been APIs
available from that. But what we've found-- I'll give you a real example. A customer that we've been doing
business with for a few decades has been using our stuff on
premise that entire time. And there was a new product
team inside that company-- and they specialize
in home security-- that discovered our
self-service APIs on their own through a paid search
campaign that we ran. And that team had no
idea that their company had been doing business with
us for that amount of time. They discovered a new
way to consume things that we've provided
for a number of years, but in the delivery vehicle
or consumption pattern that they're used to. And that was a recent discovery. But when we first
started our journey towards digital
transformation, we had some hypotheses
about what people needed. We've since learned about that. But originally, what
we discovered was, let's focus on the people
first, and what their needs are, which can help us determine
how we price things, which then informs how we build our
product, which then informs how we build our back
office, and all the supporting
infrastructure to support it. It seems almost irrational
sometimes as a product person-- as product people, we have
a tendency, sometimes, to put our products
before other things. Because we get so excited
about our own products. But if we apply a discipline
where we put people first, price can then follow. Product can follow
thereafter, and then the back office infrastructure
to support your product-- all of the things
that you need to have, in terms of operations, and
sales, and lead generation, and fulfillment, and
provisioning, and activation, and billing, and the other 80%. It starts to define itself for
you, which is a magical thing. And we certainly didn't
stumble upon it that way. So when we started
with people, we went out and talked to our
existing customer base. And what we had found was
two types of classifications or archetypes. One was a commercial developer. And the other was a
corporate developer. And we came up with
those terms on our own. But basically, when we looked
at all of our customers, we found some customers
that were using our products on premise for a long time to
build other products that they sold. And then we also found
types of customers that were more corporate nature. They were using our
products on premise to solve an internal business
problem or a workflow to gain some efficiencies. So one was sort of on the
side of generating revenue. The other was on the
side of saving money. In reality, what
we found, though, is that we're now talking
to a lot of product managers on the commercial side. So we're having product
manager to product manager conversations with companies
that want to consume APIs where you have product
people doing assessments, and evaluations, and working
with their developers at the same time to decide
what API makes sense, in order to augment or
enhance their product. So we've landed on these
types of personas, these two users or customers, that
we now see a pattern for in the two-year
journey that we've been on through
digital transformation. And so Janet is the-- we used to call a
commercial developer. And we now have
learned that we're working more with--
rather than developers, we're working with product
managers, where developers are testing things out. But then we have financial
buyers and the product management organization. And again, her
interests are she's seeking a service to augment or
enhance her existing product, or a solution that she
sells in the marketplace. Whereas Dario, what
we used to classify as kind of a
corporate developer, we found is now
more like a business process-oriented kind of person
inside a large corporation. It can work in any department
across that organization-- so like telecommunications
provider, for example. And there's a real
estate department. There's an engineering
department. There is an
operations department. And there is a
retail department, so forth, and so forth. We've found lots
of folks like that that have business process and
workflow problems that they need to solve. Where our APIs, as an ingredient
to that overall workflow and business process,
is helping them achieve the efficiencies and
gains that they want to find, and making them more streamlined
in their organization. So Janet and Dario, when we
set out on this journey-- in talking to them,
we found out that they had some common goals,
despite their differences and objectives, in terms of
generating revenue or saving money. And those common goals,
they're performance-based, whatever they were,
essentially, measured upon, in terms of their own
individual performance. Those were different. However, there must-haves
and there must-not-have were identical. It was really kind
of interesting. And we were sampling
the community, in order to find these. And some of the must-haves
are kind of obvious things. Simple, easy, self-service
learn experiences, well-documented documentation,
simple checkout flows, and learning, and buying,
these kinds of things, they both shared these. They both share a desire to
have a frictionless self-service kind of experience
where they can learn about the product themselves. They could buy the product
with little interaction-- or at least low friction-- get their access keys,
and their secrets, get started, use the
product, buy the product, and get support for the product
all in one central destination. And those common goals were what
we set out to go and achieve. So we made a
promise to ourselves and to all of our
customers that was what we were going to go and do. And it seems simple
enough on the surface. But actually, there's a
lot of stuff in there. How they learn
about it required us to work across multiple
different teams inside our company to market
appropriately and message the right way. How they bought it, we were
forced to adjust our billing practices. How they got it forced us to
change how we communicated. We had to send automated
notifications and emails about where they go. And then where do
they go from there? And we had all of these
back-office systems that each did those silos. And we had to bring
all those together. So as an organization, it
was very challenging for us. But we knew we needed
to deliver this promise. And then the things around usage
and payments were also really, really were challenging. One of the key things
we found was that-- over the years, we were working
with our incumbent customers. They said, we love
your products. But we really don't
like your process. It takes a really long time for
us to get to use your stuff. We've got to go through
this difficult contracting thing, where our lawyers are
going back and forth on things, where we have to set up and
create custom provisions. And your bills, I get
three different or four different bills from you. And I'm not sure which
product it's for. Because we have so many
products inside the company. So one of the key things
we set out to go and do is deliver unified
contracting and billing. And that enabled us to
actually deliver this promise. Because the rest of it
sort of fell into place around the marketing and learn
aspects, buying, and getting, using, and paying, and so forth. But before we got
there, one of the key challenges that we had was,
not only the complexity of the number of products
that we had, but also the variety and the diversity,
and the variable value associated with that. So pretty simple to say to
yourself, OK, I'm going to-- the customer says they
only want one bill from me and one contract. But how do I do that
for a myriad of products that all have different
value, maybe different usage restrictions,
things like that you know that we have to think about
from a business perspective? So as an example
of that complexity, one of our lines of business
is location intelligence. And within that, we've
been assembling data sets for a number of years. And we've got a
tremendous amount of data. Each one of these data
sets is different. It has a distinctive value. It has a distinctive price. And if you opened up like our
old-school on-premise beige book or price book, it
would be 800 pages long. And we can't give that
to a customer that's expecting the frictionless
kind of self-service experience that they'd want from
a modern API product. So that was one complexity
around the breadth that we had. And we needed to abstract that. The other was around variety. We've got all these
different types of data. And describing the value
has always been a challenge. But as we moved to more of a
self-service delivery model, it became increasingly
painful for us to learn that we needed
to find a way, really, to abstract away
this complexity, and deliver on our promise
of self-service simplicity across all stages of the journey
that the customer was going to go through. And then at the
same time, there was some additional
complications or complexity added in around the
verticals that we serve. So there was very
vertical-specific messaging that we needed
to do, and so forth. So as we started
thinking about this, and we started shopping
around for partners to help, it took a while. But we went from
a messy situation, where we had a lot of different
data, with different values, with different messages that
seemed overwhelming from a product manager standpoint
in order to position, and market effectively, and
help people understand without lengthy conversations,
and so forth-- some of the must-not-haves
that Dario and Janet shared-- to move to more of a model that
made sense that abstracted away all that complexity. So we looked at two things. We looked at the
Chinese menu of all of our products
in that beige book that I mentioned,
where you could have dozens of
categories with dozens of prices within each category. And you buy those
things a la carte, which means you get multiple
bills and multiple contracts-- because each one of those
data have their own usage restrictions, have their
own acceptable use policies, have their own prices,
usually their own legal terms, that sort of stuff-- to more of a carnival model. So when you go to a-- how many
of you have been to a carnival before? OK. When you go to a
carnival, you buy a roll of tickets at the door. That's your bill. And that's your contract. And then you go
inside the carnival. And you spend your tickets
on different rides, or goods, or services. And so one ride might
cost 10 tickets. Another might cost five. Another might cost
three, or two, or one, or something like that. But we took a tip from
that playbook, and said, let's apply that
to the complexity that we have around
variable-valued products and how we price them. So what we thought was, OK, if
we open up a store for APIs, when they come in, let's let
them sign that one contract that covers all
the APIs, and then get their roll of the tickets
that they can then go and spend in any way that they would
like on any and all APIs that we have at that store. So that's what we did. In working with Apigee,
we were able to introduce one virtual currency,
which we don't call tickets from a carnival, we
call them credits. And you can buy these
credits, either up front, or you can pay as you go. So there is both prepaid
and postpaid options. There's one unified contract. And there's one unified bill. And those were the
common two must-haves that had the most pain
for both Janet and Dario that we went to set out
and go delivery against, in terms of our
promise that we wanted to give all of our customers. When we did this, it
was really important for us to do that unified
billing and contracting. Because we wanted to do
everything self-service. Because we'd never
done that before. And selling on premise,
over the years, we were pretty good
at selling upmarket. But once we got into the
mid-market and the down-market, where folks wanted to
do things on their own, it became difficult. But through
the self-service delivery, we essentially came up
with prepackaged plans that allowed us to automatically
provision our monitoring systems for transactions
that were being used, automate billing,
automate contracting, all of the things that reduce the
friction that made it complex. And we removed the comments
like, we love your products, but we hate your process. So we've really
fixed the process, which I call the other 80%. And we did it specifically
for self-service. Now that said,
what we've found is that self-service,
in and of itself, requires all of us things
that Bala mentioned, in terms of iterating
and capturing metrics on how you're engaging,
retention marketing things. Sol like once they sign up, and
you collect that sign-up data, you're putting that somewhere. And then you're monitoring
their transactions. Are they active, or
are they inactive? If they're inactive,
what's your campaign? What's your outreach strategy? If they're active, what's
your outreach strategy? Who do you assign to that? How do you do fulfillment
and follow up? How do you get them to
upgrade or downgrade? Do you let them swap
out their cards, and all those kinds of things
that are in the other 80% that we have to think
about as product people? Or else we're going to end
up on the phone handling all the customer support
escalations, which none of us want to do. So we get it right
the first time. But that said, that was my plan. And I thought that
self-service would work. And what we found is that we
had a gap in several areas of the business
where we still know we need to improve,
particularly around retention, and communicating, and
opening up a two-way dialect and channel that's digital. We're still going to
continue to work on that. But as a result
of what we learned from the self-service
channel that we opened, we've decided to
go back to using our direct sellers, who've have
been selling on premise for so long, to come and now sell these
self-service things, as well. So I guess the
point of that being, or that point of that story,
is that we all, sometimes, have a vision at the origin,
or at the beginning of where we start. And the journey
takes us in a variety of different directions. And we persevere. And we pivot. We've recently gone
through a pivot change. But all of this we couldn't
have done without Google's help. And I mentioned that point
around the direct sale stuff, because it's going to
introduce a whole other set of complications that are
different from the way that we set up self-service. And they're going to be
things like, how do you set up custom plans, and
then provision those, and create custom bills,
and things like that? So there was another
session track, I think earlier today,
about how that's going to be done going forward. And Google's made another
acquisition in that area. So we're pretty
stoked about that too. Because we know that
that's an entirely set of new complications that
are right in front of us. In fact, we're seeing that now. Thank you. [APPLAUSE] BALA KASIVISWANATHAN:
So I always find it fascinating
when you have customers-- let's talk about
this for a couple of reasons. Number one, especially being
in the Bay Area and Silicon Valley, you get used to fairly
cutting-edge technology, cutting-edge businesses, which
are built like over the last 10 years, or five years. And the speed at which
you can innovate and do interesting things
is very different. And then to see a company
like Pitney Bowes built a business over last 100
years, I guess, right? JON SPINNEY: That's right. BALA KASIVISWANATHAN:
And then trying to do the shift with all the
importance of the existing business, while trying
to shift and create a new way to do the business. And that's the challenge. That's really the challenge. Because if all of us product
managers had a clean sheet, and we could go
build a product, it's become so much more easier. But all of us live
in the real world where we have to deal
with constraints, which are our existing
business constraints. And sometimes, what happens
is the constraint is money. Like you can't just go
to town, because you don't have the money to
go market raise awareness. In turn, sometimes, we
don't have the right product features. And one thing, none of
us have enough engineers in our engineering
teams ever, right? So all these constraints
happen to all of us. So the question is, how do we
do the right thing, in terms of opening up, and
driving the business, and then innovating
as we go forward? So hopefully you've got some
real, unfiltered feedback here from Jon. And I kind of requested him
not to paint, necessarily, a rosy picture, nor a very dire
picture, but a real picture, so all of you can take
away the right things, and think about how it
impacts your business. I almost felt, Jon, that
your talk could land up in the classic meme, where
you have what I think I do, versus what my mom
thinks I do, and what really happens kind of thing. I think you could do
some version of that. But to wrap it up
here, so what are we going to do just
kind of reinforce what we've been telling, I
think, through the session. Number one is, if you're
an API product manager, and you are thinking about
API product management, absolutely focus on
your developer personas. And I'm calling them
developer personas, because Jon correctly
pointed out, sometimes, these are
product manager kind of people on the other side. Sometimes, these are
actual developers. It depends on your business,
and what kind of APIs you have. The second one, I think,
which is loud and clear, and I'll say it once again,
is please make things easy to access and discover. I cannot insist on this more. Because the one thing
I think everybody is getting used to is going,
and searching, or discovering things themselves
before they actually want to talk to somebody. And if you're not
surfacing in the way they want to consume your
information upfront, you lose them way before. So please, please make sure
that it's available very easily. And the reason you have
a developer product PitneyBowes.com, or any
of the other sites-- and make sure it's indexed. Make sure it's
available on search-- is that you are
going to find people doing exactly what you do. When you're going to buy
a gift for your partner, or spouse, or your
kid, you go and search. And everybody does that. And you've got to make sure that
your product is discoverable, and then from there,
it's easily accessible. And APIs are no different. The last one is, please
remember to deliver a consistent experience. And when I say
consistent, I'm not suggesting that you deliver
a white glove experience. There's a difference. There are products for which you
need a white glove experience. But consistency means, every
time I interact with you, I know what I'm
going to get back. So as long as that is
there, I'm OK with it. But if, like Jon was saying, if
I go for location intelligence API, and I get one experience,
and I go to something else, and I get a different
experience, I'm going, this is the same company? Come on. What's happening here? So it is not about the
high touch or low touch aspect of it. It's about the consistency
of the experience you want to deliver to your developers. That's the most important thing. That brings people back. And they know what to
expect, they are productive. You can then improve. And every time you
improve, they can see that you're making the
change, which is consistent, as well. OK? Thank you again for your time. And Jon and I will be around
for any other the questions. Thank you. JON SPINNEY: Thank you. [MUSIC PLAYING]
