Implementing “APIs as a Product” Strategy feat. Olivia Califano, Sr. Product Manager at Procore Technologies

Show Notes

This week on the API Intersection podcast, we spoke with Olivia Califano, Senior Product Manager, API & Developer Tools at Procore Technologies, a construction management software company. Procore is focused on connecting all the stakeholders in a construction project, from owners to general contractors.

Olivia focuses on API governance and developer tools, ensuring that teams are building with consistency and following best practices and standards. She primarily focuses on internal tooling to support their larger API strategy and external tools such as their API reference documentation and SDKs to help developers onboard.

To subscribe to the podcast, visit https://stoplight.io/podcast

Do you have a question you'd like answered, or a topic you want to see in a future episode? Let us know here: stoplight.io/question/

What is API Intersection?

Building a successful API requires more than just coding.

It starts with collaborative design, focuses on creating a great developer experience, and ends with getting your company on board, maintaining consistency, and maximizing your API’s profitability.

In the API Intersection, you’ll learn from experienced API practitioners who transformed their organizations, and get tangible advice to build quality APIs with collaborative API-first design.

Jason Harmon brings over a decade of industry-recognized REST API experience to discuss topics around API design, governance, identity/auth versioning, and more.

They’ll answer listener questions, and discuss best practices on API design (definition, modeling, grammar), Governance (multi-team design, reviewing new API’s), Platform Transformation (culture, internal education, versioning) and more.

They’ll also chat with experienced API practitioners from a wide array of industries to draw out practical takeaways and insights you can use.

Have a question for the podcast? DM us or tag us on Twitter at @stoplightio.

I'm Jason
Harmon and this is API intersection

where you'll get insights from experienced
API practitioners to learn best

practices on things
like API design, governance, identity,

versioning and more.

Welcome back to API Intersection.

So I know lately all the time I'm like,
Hey, let's do something

a little different today.

But I'm just going to say this is a thread
we're on and I'm loving it,

which is kind of API as a product
and people who work in the product

field around, you know,
how do you manage APIs is a product

that's been around for a while.

But I feel like in the last few years
this is starting to firm up as a more

and more normalized thing, but
it's still somewhat an emerging practice.

So like just love sharing
whatever we can learn about it.

Joining me as

usual lately, Anna Daugherty,
thanks again for joining in it.

Thanks for having me.

And our guest today is Olivia Califano,
who is currently at Procore,

but has done all kinds
of interesting things outside of that.

Olivia,
tell us a little bit about yourself.

Hey, everyone, really happy to be here.

Yeah. So my name is Olivia Califano.

I'm currently
a senior product manager at Procore,

which is a construction management
software company.

So we really try to connect
all the stakeholders

in a construction project from your owners

to your general contractors
to even your specialty contractors,

to allow them to collaborate
and stay connected in one platform.

So I'm currently the senior
product manager on the ecosystem division,

which is essentially enabling developers.

So that could be a customer developers,
but also third party developers as well

and even our internal teams to build on
top of our platform by leveraging our APIs

and my focus is on API
governance and developer tools.

So on the API government side, it's
really ensuring that teams are building

with consistency, sort of ensuring they're
following best practices and standards.

And then in terms of developer tools, it's
focused on internal tooling

to support that strategy,
but also external tools as well,

like our API reference documentation

SDK is to help developers on board
as well as some other capabilities

like rate limiting and web hooks,
which is to allow customers

to sort of receive notifications
about what's happening in our platform.

Well, it's

safe to say, Olivia, you're our people.

That got it. All right. Yeah.

So that's an all the things I should have
mentioned, too, that I think part

of what I like about the subject matter
today,

you know, procore where you work is

these kind of more traditional industries
that we just I know it's not like

we're seeing this all over the place,
like that's our top customers.

This traditional industry
is not software companies.

And in a kind of modern sense.

Now, I know Procore is,
I think, kind of a little more

on the software company side, but sort of
trying to disrupt a traditional industry.

But I think it's like
when we talk about APIs, people go,

you're talking about construction. What?

I know, right?

Yeah. Yeah.

And it's actually
a really unique position right now.

So we're we don't always have this

opportunity to ride the beginning
of an industry transformation,

yet construction
is this really ripe area, right?

It's ripe for help and doesn't really
understand tech all that well just yet.

So, yeah, we're like,
come help us innovate.

And there's a lot of opportunity right now
to just take advantage

of the ongoing wave of technology.

So we kind of saw in the show notes
you had like this

this notion of kind of a guild
internally or,

you know, it's getting folks
together around in

you already mentioned like best practices
and all this kind of stuff.

How did that come about?

And like where you kind of add on,
you know, that the effectiveness of that.

Yeah.

So at the end of the day, what we're
calling the API as a product strategy

is this fundamental culture shift
in how we think about our APIs.

So it implies that an API drives
significant business value

and it shouldn't really just be treated
as a technical artifact,

but we need to start thinking about it
as a product

fully deserving of proper design
thinking, customer research, prototyping,

really everything like long term
monitoring and maintenance.

So this strategy really came about
because customers actually came to us

and started to complain
about major limitations

with efficiency, but also performance
issues like big performance issues

like they were hitting response times,
they were receiving timeout hours,

they maybe maybe the API, for instance,
wasn't designed efficiently.

So they had to make multiple calls
to actually get the data they need

and they didn't know the types of calls
they needed to make.

So this is sort of
how the strategy came together.

It started as this sort of grassroots
campaign where it was just myself

and two others, Oscar Garcia,
who is an engineering manager

at Propper, as well as Mark Tyrrell,
who our platform architect.

We were like, Hey, something fundamental
needs to change in how we're thinking

about APIs and API design
because we're facing all these problems.

And at the end of the day,
it wasn't a bad thing, right?

Like we're seeing some issues just because
of sort of this rapid organic growth

where we were just trying to deliver API
after API or endpoint

after endpoint to sort of meet
the demands of our customers and partners.

But yeah, at the end of the day,
we also need to come back together

and refocus
on sort of key areas of tech debt,

but also kind of align the company around

for design principles and best practices
for designing APIs in the future.

That's so that's really interesting.

We've been talking about the culture shift
problem

on this podcast for so many episodes.

It's interesting that you all three across
the organization said, We need this.

How did you get buy in
from the rest of the business?

How did you pitch it to them?

Yeah, so getting buy in from
our stakeholders was actually

our biggest challenge.

So as mentioned, the strategy
kind of started from the bottom up, but

at the end of the day, this really needs
to get the buying of everyone.

So not just product, not just engineering,
but also our executive team as well.

So after we came up with the strategy,
we started presenting it across different

teams and channels and then eventually
took it to senior leadership.

But it wasn't really until customers
started complaining about these problems,

like the performance issues

and scalability issues
and actually potentially threatening

renewals and new deals that executives
ultimately bought into the strategy,

as is a classic
story of what I call the Band of Rebels.

Right.

It's like the people who are facing
the pain that no one else

realizes yet getting together
to try to get a handle on it

and then tell a bigger story
with the end goal of,

you know, get some kind of bigger support.

Did did that result in any sort of
like funding, any sort of program

around this stuff or like getting more
dedicated people's time to it?

Or was it just about getting all the right
players involved?

For us at least, it was more about getting
the right players around it.

Sorry, in the

so like one thing to highlight

is that our APIs are completely free,
they're open and public.

So there wasn't really
that immediate tied to sort of revenue.

And for that we had to dig a little bit
deeper. Right.

It was, hey, getting the performance data
in front of our executive team,

kind of talking to them about sort of
the big issues that customers were facing.

And so in terms of an actual program,
it was more like no, like, hey,

they were just kind of giving us support
and telling us to go after this

based on these problems
because it was affecting real issues,

real customers,
and sort of these real problems

in terms of actual funding.

We're potentially looking
into using some of our learning

and development budget
to just sort of help

get some additional training and tooling
across our individual product teams

and engineering teams to get them more up
to speed on sort of the API mindset

and tools and techniques that they can use

to implement this for the future.

How many tooling or how many product
and engineering teams do you have

right now we have from 15 to 20, so

yeah, so we have a number of

I guess the way the
the organization is structured

is we have product and technology
under one band.

And so under that we have the product
or we also have the engineering word

and for each tool that prop warehouse,

it might be like the RFID tool
or the SUBMITTALS tool.

We have a dedicated product team
and under that we have yeah, engineering

support as well.

So this is, is actually interesting
as we're going out

and evangelizing the strategy

because we're going across
individual teams to really promote

the strategy and capture
and hone in on their specific

feedback for how we should implement it
at their level.

So it's kind of great
to have these smaller like 10 to 15 person

feedback sessions
so that we can really again

focus on their feedback,
implement it into the core strategy,

and then continue to evangelize
across the company.

What's been the adoption?
How are they reacting to it?

The feedback has

been generally positive,
so we're still going across and roadmap

or we're still going across and road
showing to a number of different teams.

But again, like our first big
milestone is to really align

the company around this problem
and how we can fix it.

And it's been going really well,
so it's pretty awesome to see that aha

moment in the audience where they're like,
Oh yeah, we have a fundamental problem

and we really need to fix something
at the end of the day.

So this is sort of
one of the success measures

that we're using to understand
success across the strategy.

Just because, as I mentioned,
this is a long term

strategy,
it's not going to happen overnight.

So yeah, really getting the buying
and adoption across the team

has been really overwhelmingly
positive, which is great.

Nice.

Yeah.

Sometimes it just takes someone
to recognize it and have some tacit

authority to recognize that just makes

everyone feel like it's okay.

It sounds like there was

a little bit of a case of build it
and they will come in terms of like,

you know, we built some APIs,
but no one really knew

what exactly
they were going to contribute.

And you've had to sort of reverse
engineer,

why are these things valuable
and why is this important?

Like, what are some of the highlights
of what you came away with

on the sort of success measures?

So our strategy is broken up
into two parts.

So the first part is kind of going back
and fixing

the issues that have accumulated
with our existing APIs.

And for that, we've identified
five key areas.

And then the second part

is starting to think about
how we can design for the future.

Right.

So aligning the company around
those core principles and standards.

But as it relates to the first part,
those five key areas,

we've been able to measure success
across each one.

So I can go into a few of the areas,
but it's things like accuracy, right?

So ensuring that your API documentation
matches

your implementation
and then performance as well, right?

So ensuring that customers aren't hitting
high response times or hitting timeouts

and just making sure
that we have a pulse check on performance

issues across the API space.

So for both of those categories,
we are measuring

success across each one and those two
are actually the focus for 2022.

We can't really tackle all at once.

So the other three which relate
to consistency across our API space

as well as efficiency and coverage,
are going to come in 2023.

But for those first two, we are definitely
making strides to kind of understand

the sort of like the performance issues
we're facing.

And we've built a health dashboard
to help teams do accountable

to their performance issues and needs
then around accuracy.

We've also built an in-house tool

that allows teams to integrate
their endpoints with the tool.

And the tool then

processes the data
and outputs this to a reporting tool

that enables teams
to kind of better understand where

accuracy issues exist
within their documentation.

It actually generates
what we're calling the API accuracy grade.

And so we've been able to track
not only that, teams are adopting the tool

and leveraging the tool and integrating
the tool into their developer workflow,

but also that they're seeing an increase,
a positive increase

in their API accuracy rate as well.

So you're you've got a tool that's helping
you figure out if documentation

matches implementation that I hear a lot
and it's a really important need right now

because you can imagine developers
coming to your API space

and they're encountering all these issues,

right, where the response
that's displayed in the documentation

doesn't actually match the response
that out, it's out, put it in their code.

And so they come to us
and they ask these questions like, Hey,

can you provide an accurate example
of what I should be looking for

or accurate error codes, right?

That should be returned in the payload.

And right now it's it's this huge learning
curve for our developer community.

They're not really able
to successfully integrate.

We're seeing major

sort of major increase in time to first.

Hello from when they maybe
authenticated with their API

and then eventually make their first
hello world call

just because they're not able
to figure out sort of how yeah.

How, how the API actually functions
and it's not their job.

Right. To,
to figure out those discrepancies.

So this is really cool and innovative
of you to fix that problem from that.

So many people are facing
an every industry is like how do we match,

how do we how do we ensure that
we're matching without one

single person having to go back
and figure it out every single time?

So that's no and at the end of the day,
it's not rocket science and everyone's

trying to do that. Right?

Just build a better AI platform,
build a better documentation portal.

And so,

yeah, this,

this is definitely just an area of tech it
that we're working to correct.

But of course, it's also like,
hey, these are high priority areas

when you're building a new API,
focus on accuracy, focus on performance,

kind of get ahead of it so that
these issues don't creep up in the future.

Are you using any sort of
like spec formats

or anything to generate documentation
or is everything sort of

in a hand-curated state right now?

Yeah, we're using open API spec 3.0.

So we actually just did a major migration

from Slider 2.0 to OS 3.0.

And this is actually pretty integral

as a best practice for treating our API
as a product.

Right.

We're telling developers that,
hey, if you're building a service

with an interface,
then first start by designing the API.

First,
keep your customers front and center,

but also create the API
specification early

and share it with your stakeholders early
so that you can collaborate and feedback

can happen early to catch any issues
and prevent issues down the line.

So we're really trying to get teams
to be intentional with that

standardized documentation
with the open API spec

so that they can actually use it
as part of their development process.

That way, by end of that one obviously

are aligned here.

And so,

you know,
for maybe more kind of traditional product

manager folks who are trying to figure out
this API thing, you know, they might

listen to the last few minutes and go,
I have no idea what you're talking about.

So what does all this have to do
with kind of API as a product?

It sounds like a lot of operational
and documentation and all these things,

like how do you see it
looking at it as a product manager?

Yeah, well, product managers are fundamental to the success of the strategy. So

I think

Ofer start by providing some background
into who our customers are

and that can help elucidate like why
we need product to be fully bought in.

But essentially
we have three primary customers,

so we have the actual customer, right,
who's buying

the technology, who's in the app.

We also and they're potentially
creating custom integrations

by leveraging our API to just compliment
their day to day workflow.

We also have those third party
integrators, so what we call our partners,

their third parties
who are building apps for Marketplace.

And again, these are apps
that ultimately our customer who's spot

procore can leverage install again
to complement their day to day workflow.

And finally, we have our internal teams.

So I think where product really fits in is

we're so hyper focused
on that first bucket, that first audience,

which is the pro core customer,
and we're not necessarily considering

those broader use cases of our partners
as well as our internal development teams.

So even our mobile team
will often come to me and say, Hey,

I think Procore is is building
a lot of APIs just for the web

implementation like this
just is not working for the mobile teams.

So it's really important
that product managers start to understand

the real customers, the real use cases
and user scenarios of who's going to be

using the API and just make sure
that they're documenting

those use cases per for each audience,
click it.

I think that's really where
product managers can play a critical role

in the success of API as a product,
making it less about specific delivery

and more about strategy
with the wider vision.

Yes. And starting early, right.

So if they're creating,
I don't know, a product brief

or some sort of opportunity assessment,
it's clearly outlining those use cases

and then going out and actively doing that
customer research with each of those

audience types to fully understand
how they're going to be using the API.

Right.

So as I mentioned, one of the areas
was efficiency and might be

a partner
now has to make a series of calls

to get the data that they need
instead of just one API call.

It's probably because we didn't do enough
discovery around

how they were actually going
to use the data or use the API

and sort of what data they actually needed
from a specific end point.

Yeah, it's interesting

how like the default state
we've been trained

into over the last 20 years
is build a webpage, right?

Like you have a screenshot in, you know,
whatever your favorite design tool

is, you've got some wireframe

and then everything else
is an implementation detail.

And we had kind of the mobile
first wave that I felt like came

and then kind of died off a little bit
in the sense that some places just went,

Oh, that's hard.

I don't have enough mobile adoption.
It doesn't matter that much.

But from an API perspective,
taking that mobile

first view is a super strong
forcing function.

To make you think about the underlying
API has to serve more than one thing,

not just the web page. Right?

So super powerful in keeping

like the right capability
oriented perspective.

Yeah, definitely.

So my understanding of procore

in some sense is that there's sort of this
marketplace, a value exchange between

your buyers,
kind of the customers who are looking for

these different sort of suppliers
and and doing their construction work.

So to some extent, there's a marketplace
going on here between the supply of your

providers and your customers
looking to buy things like,

you know, how does that
whole sort of marketplace thinking maybe

fit in to how you're looking at APIs
and your strategy?

Yeah, there's definitely a lot of business
value around the marketplace strategy.

We actually have a dedicated

PM, solely works on Marketplace
and a lot of our strategy is around

sort of diversifying the types of partners
that are building on our platform.

So we want to focus on
all the different stakeholders.

As I mentioned, we're collaborating
in a construction project,

so not just focused
on partners, we're building

apps for the general contractor,

but also starting to diversify
and think about partners

who are potentially building
for the owners or specialty contractors.

Even so,
there's a lot of thought into like,

hey, that outreach kind of going out,
making sure that our APIs are able

to support those different audience types.

But also, yeah, making sure that we're,
we have this diverse

partner audience
that's coming and building with us.

Nice.

Yeah. It's

it's interesting how often

that we see this intersection
of like API platform

build outs
that it just naturally lends itself to

the folks that are integrating
tend to be supply

and the folks that are using
the integration in a more pushbutton way

tend to be kind
of your consumption side. But

it's weird when sometimes what,
you know, like

talk to say stoplight customers or
just other folks around and you go like,

what are you doing about, you know,
is there any marketplace thing here?

And sometimes it's kind of this I know.

And then you go,
But isn't this supply and this and this?

Oh, gosh, I guess we are.

And so, you know, I feel like it's a thing
that if people aren't mindful of

that, you have potentially two different
strategies running into each other, right?

One that's sort of architectural
or integration focused, and one, that's

how to grow a marketplace.

And those two things have to fit together.

So it's cool to hear that
you guys are doing a bit of both.

So, you know, it's interesting to see
that you guys are somewhere

along the journey here and I love
and really appreciate your transparency

and kind of going, you know,
we kind of have some problems here

that we're having to tackle, right?

That's the reality
a lot of times of building out a platform.

If you kind of had

to turn the clock back and you can go back
and make some of these earlier choices

that would have prevented
some of this pain

or kind of the right way
to set it up from the start.

How would you how would you approach that?

How would you do it
if you got to start over again?

Yeah, this kind of ties back
to just the biggest challenge,

which was ultimately getting executive
and stakeholder buy in.

So really, if I had to do it again,
I would present that performance data

much earlier to our executives
kind of showing like,

hey, these customers are getting
these long response times.

They're not able to scale

and really find that type of revenue
a little bit earlier on.

I'd also maybe turn it back on them
a little bit.

So kind of understand, hey, like where
do you want to go as it relates to scale?

What do you want?

Our platform to be in the next five years
and kind of help educate them that, okay,

in order to get there, we can't just keep
throwing out more features, right?

We have to build

a robust platform underneath and this is
what's going to allow us to scale.

So I think

if you can get them to buy into that,
you can sort of get some investment

at the beginning.

You know, it's interesting

how often, you know, that sort of
we ask this question a lot, right?

How often it's like, oh, well,
you know, we would have been better

about being more consistent upfront.

But I really appreciate that product.

Folks get that it's, you know,

have the business strategy
aligned with the API strategy, right.

That that is the more fundamental
sort of primitive thing

that if that's not right,
you can have beautiful

consistency and amazing performance.

But if you're not actually building
in the right direction,

you're not growing the business.

That's how you get defunded.

That's yeah, I love that perspective.

Well, Olivia, it feels like that's
kind of a good wrap point.

Any other sort of closing thoughts for us?

I'm just I think perseverance, right.

If you sort of are starting
in the early phases of API

as a product strategy design,
just keep going at it,

just make sure to document everything,
kind of reach out to teams proactively

to understand their problems with
maybe how they're building APIs currently

do proactive
research research out to customers.

Meet with your API support team.

If you have an API support
division, just understand,

then start to bucket those customer
frustrations and then take it from there.

Like I definitely recommend prioritizing

the yeah, the different pain points
into those buckets

and then finding those key areas that

then you can start to practice
and reach to your different teams.

Very nice.

Well, again,
appreciate all the the open sharing of,

you know, some of the struggles
and where you're out in the journey.

And we'd love to check back at some point
in the future and see how it goes.

Sounds great.

Yeah, I look forward to that.

Thanks for listening.

If you have a question you want to ask,
look in the description of whichever

platform you're viewing or listening on
and there should be a link there.

So you can go submit a question

and we'll do our best
to find out the right answer for you.