Tips on How to Become a Better Product Manager feat. Ikenna Nwaiwu, API Product Owner at 10x

Show Notes

This week on the API Intersection podcast, we chatted with Ikenna Nwaiwu, API Product Owner at 10x Future Technologies. What helped Ikenna Nwaiwu become a better product manager, a more well-rounded developer, and craft a stronger API strategy was focusing on creating APIs with a product mindset and a design-first approach.

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 Podcast.

We have totally one of these wheelhouse
discussions today, right?

The thing we've done most is look at,
you know, kind of what our,

what our API programs
and kind of the, the machinery behind it.

What does all of that look like?

And today's guest, Ikenna,

from 10x Future Technologies, kind
of coming from the banking world a bit.

But he's a product owner which you know,
we love API product people.

They're a rare breed these days.

So Ikenna, thanks for joining and Anna,
my co-host here,

Ikenna tell us a little bit
more about yourself

and kind of what 10x does
and then we'll we'll get into it.

Thank you, Jason. Thank you Anna.

Yeah.

Like Jason said, my name is Ikenna Nwaiwu,
I'm the

product owner,
the API product owner at 10x.

So 10x is a kind of a global SAS company

and we built the protocol
10x super core platform.

It's a product
we build for our clients who are banks

and it's really to help make banking
better for, for their customers,

for our clients and really for,
well for the world really.

But the goal of the platform, it's
a kind of cloud based platform

that that really helps to make,

helps our clients build product
to market ten times faster.

And it's a much lower cost
to to what they have.

So that's, that's kind of
that's what we bring to the market.

And in terms of my role
there as an API product owner,

I kind of help oversee API platform team

I team the team
we have which kind of oversees API Gateway

but also oversees kind of API governance
standards,

help optimize our API development workflow
and also

I help facilitate
the internal committee of practice

we have around APIs,
which we call our API guilds.

Yeah.

Your people are kind of your people.

Yeah, exactly.

And that's it's
quite bold, right, to call your company

ten X
because you can deliver ten X to speed.

Yeah,
I'd love to hear where that came from.

Yeah, that's, that's aspiration.

Yeah. So we're going to do aspiration.

All right. Good.

So we've certainly seen

you know, plenty of trends around kind of
fintech and general investing in APIs.

So how long has ten been around
and have you, I guess, been around

long enough to have seen the bump
from the last couple of years, I assume?

Yeah, we've been around for
about five years, but I joined a company,

I think it's been 18 months plus,
you know.

Yeah,

so had been there
long enough to be disillusioned a little.

So you're going
to give us some dirt, right?

Well,

yeah, yeah.

The trajectory is,
I like to say it's leading a little better

since I joined, but, uh,

yeah, that's the idea.

No, I just mean, you know, everybody loves
stories of failure to write.

None of us really know what to do.

We just know a lot of what not to do.

So, you know,
we were kind of chatting before,

and it certainly seems like,
you know, what your kind of job here

is, is this this idea of kind
of the whole lifecycle of an API

and kind of the workflow
that happens behind it.

And you kind of used

to run around this term of API ops, which,

you know, I feel like it's like API first
or anything else.

Everybody has their own definition.

So I'm going to throw
your label away for a second,

but tell

us what you mean
when you're kind of talking about API ops.

Yeah, that's a good, good point, Jason,

because I think when we look at it,
you know, we've had a dev ops movement

and from there there's been a lot of,
you know, the next term that's come out.

So there's been a lot of ops
related buzzwords come out.

You know, there's is dev ops,

dev ops, everything ops just,
just coming out and sales and.

Yeah, yeah, exactly right.

And I've, but I'm building been interested
in this idea of API ops

because when we look at it
and look at what

you know when we start
what's dev ops about, right?

And we see that, you know,

and it's kind of hard at its core like
I see dev ops as really applying

lean principles to the two,
to the software development work stream.

Right. And trying to optimize that.

So optimizing the flow of value
to the client, to the customer,

but also getting feedback along the way,
you know, whether

that true metrics or different ways
getting feedback

to further optimize that process
but also about, you know,

putting safety, building cultures
that incorporate safety,

that incorporate continuous improvement,
that incorporates experimentation

to help drive cultures that innovate.

So that's really for me
what dev ops dev ops is about.

And then from there,
when we took over API ops, it's for me

it's about applying those same principles,
those same dev ops principles to API.

So when you look at an API delivery
and API value stream,

how value is delivered around
that API changes, whether that starting,

you know, obviously that stands with,

you know, understanding some value
that needs to be delivered via an API

and then going through to the actual
API design, building the API, testing

the API documenting and publishing the API
and then supporting the API.

And sometimes, you know,
you'd also get to deprecating that API

and so on setting that API,

you know, how is value
delivered across that whole value stream

and how can you optimize it, you know,
reduce waste and make it more efficient,

but also get the learnings,
get the feedback to to help design

better APIs and deliver
better value and for, for the customers,

but also help the teams
who build this APIs, you know, explore,

you know, be innovate, you know, build,
try new technologies, not hold them

back, you know, not be the bottleneck
bottleneck, right to API innovation.

So for me, that's what API ops is about.

Wow. That's

I hope you have notes in front of you
because if I could ever rattle off

a list of a life cycle that cleanly,
I would just give myself

a huge pat on the back but that's awesome.

The part I really would love to dig into
is that first bit is when you say that,

you know, let's talk about
what is the value of this API brings,

what is that like kind of
how do you approach that sort of thing in

a, I think one in terms of, you know,
what's the shape of the discussion

or kind of the tools that you're throwing
at that, as well as how do you make that

scale across an organization and defining
value and, you know, common ways.

Yeah, yeah. I mean, for us, it's index.

In fact, before I come to that,
I'd say that question is really it's a

it's like a product design question
because as you know, these days, people

which throw around the term,
you know, API as a product

are approaching APIs as a product
or managing API as a product.

And it all starts with that, right?

It's like, what's the value?

What's the value proposition
of this product to the market?

OK, what's the product
promise to give to the market? And

and a lot of it starts with that.

Why question right?

And for Rosa next, one of the ways
we do this,

we have a product development framework
we call 63, two, one.

It's a very interesting name.

I won't go into
why it's called that. Right.

But the it's about
it has about four stages.

And the first stage is where we

we start with a problem definition
where we would try to define

what's the problem, you know, what's the
what's the problem statement here.

What what problem
what problems are customers facing?

How is this same problem being solved
in the market across different,

you know, providers
and what's the key value

that that a solution to
this would look like?

And so we start with that problem.

Problem definition and we also Waveland
incorporating more and more things like,

you know, jobs to be, the jobs to be done
framework and using that

to think about the jobs, what's the job,
the cost of my starting to fulfill

and what are the various ways
they could fulfill that job. Right.

So that's all I'm trying to define.

That's all trying to define the why,
the problem,

making sure everyone understands it and
we're only a few workshops we call them,

you know, we can have a problem workshop
if you like,

where we really explain this things

and and really produce artifacts from this
to make sure

that everyone involved understand
what's the problem being solved and why.

OK, that's the like step one.

OK, and then from there
we come down to the where

we don't dove loo when we accept that
this is a problem that we want to solve,

we go, OK, what does a solution like for
this look like?

OK, and then we go into more kind
of high level solution design

and from that we produce a few artifacts
which we

get, you know, whether that customer
journeys through or service

service design diagrams where we go
through and make sure that we understand,

you know, what a good high level solution
looks like.

And from there I think that's where
the API side now comes comes up, right?

Because when you're building a platform
your API is obviously your interface

to your platform.

So we need to understand

how the API interface fits
into those service journeys.

Right?

So I think that's from where at that point
we start talking about APIs

but at a high level.

And then we can go on to further stages
of the framework where we we go

into more detail
on what the, you know, the API activities

and what exact steps or, or,
you know, end points and so on, why?

But that's our general approach.

So in that first section where you try
to discover the problem, right?

Define the problem,

define what a solution could look like,
who is in the room for these discussions?

Who do you bring together?

Good.

So our product managers
kind of lead that we have

our product managers
who go out who talk to our clients,

but they probably lot
a lot of people involved because

it involves different stakeholders.

But we have, you know,
principal engineers who are involved.

But a lot of it is talking to the client,
understanding the problem.

So whoever it is with whoever it is on
the side of our client we're talking to,

but also going out into the market,
you know, understanding how.

So there's a lot of market
research there to understand

how is this problem
being solved in the market?

What do other providers do? Right.

And and defining that
that that kind of job.

Yeah,

so perhaps this sounds naive, but

and this is certainly flavored
by my own perspective.

But everything that you listed off,
let's define the problem

you know, what's the job being done, high
level solution, these sorts of things.

Isn't that true with any product? Exactly.

And I guess the follow up to
that is how does that sort of process

look any different because you know that
the product is going to be an API.

Yeah,
I think I like like from my experience,

I think that's been one of the challenges

of APIs because people treat APIs
as if they're not a product.

Right.

And and it's this whole technology
it's just that, you know, it's just

just an interface. It's
just a technology interface.

And so and so it's kind of

left for the technology function,

but I think it should be led by the
you know, I don't think that's right.

I think it should be led by product
because we should apply all these good

product management principles to the API,
understand the value, understand

you know, the product roadmap,
you know, clearly define the product.

And then from there
we start talking about, you know,

what's the interface
that this product should have, OK?

And I think that's where the API bit of it
then comes out from that, right?

Like, like making sure we understand it.

The, the,

you know, the interface and then obviously
designing that in the face or going to,

you know, product design, sorry, API
design methodology and all those things.

But then we can also prototype
that interface

because that's the power of API like,
you know, with, with the powerful API

specifications,
we have, you know, open API

and the graphical specification
and other specifications

that we can actually design those specs,
try them out with the consumers,

get their feedback really on
we don't need to build the API.

And I think that's
the power of this, which

I think will be really good to see

lots of teams

do this because, you know, sometimes
we talk a lot about API design first,

but it's good to actually see
like how many teams actually engage

the consumers and other stakeholders

with those with those specifications,

with those API designs and actually
get real consumer feedback from them.

To help improve the API.

Right, because that's one of the big
benefits of API design us is in it.

So and so that's I think where, where,

you know, APIs with API is
we can put it out quickly, we can get good

feedback, we can iterate quickly
to improve that design.

And then yeah, really that's, that's yeah,

as I've said on here more than once,

you know, when people go,
what do I do to manage, you know, manage

API as a product, you know,

a little old school product management
never hurts is a good place to start.

Right

those principles

should be completely applicable

you know, the stakeholder
being a developer doesn't really matter

that much until you start
getting into that interface design.

But I'm totally with you that like,
no, the problem you're solving

no the job that you're doing
for the end user.

One thought, though, is that

I would always found
that the biggest struggle

when you get into that kind of design
phase, OK, now we understand what it is

that we're going to go
build. Let's design something.

What do we call it?

Are you sort of looking
at that sort of product homework phase

what did you call it like?

I don't know the value definition

that you're doing anything there
to sort of gather up

what how we might approach
naming this stuff,

because that seems to be where,
you know, the worst starts

when you get engineering and product
and business people together.

Like everybody has a different acronym
and the customer doesn't know any of them.

And marketing wants something snappy
all the time.

Yeah. You want to get to that? Yeah.

No, it's it's a it's an actually,
it's an interesting one.

And I think it's a difficult problem
as well.

It's not exactly easy one,
but I think that's

where this stuff starts. Right.

I think is that there's a lot of tools
that we have there that can help it.

I really like

one of the first things is

really helping to define

API profile.

I think that really helps

where you say, right,
if this is, you know, if this is an API

and what are the capabilities
at a really high level now,

what are the business capabilities
we want to expose in this API?

Right.

And what are the what's
what's the general technology

we want to use this as a rest API.

Is this a, you know, Graphql API, is this

jobs API?

Whatever.

So you mean so
then you mean technology capability?

It's not necessarily business
capabilities. Sorry.

The word capabilities
can mean a lot of things.

Yeah. Yeah.

So at this point, I'm thinking of business
capabilities, right?

So you know, so for us, for example,
what would be we need

we need to, you know, for example,
we need to onboard a customer

on our platform, things like that. Right?

And so business capabilities

and then, you know, at a high level
thinking about things like usage

scenarios of the API, is this

roughly what kind of traffic or limiting

you know, traffic, traffic limits
and things like that will get any API

so that so a few high level
things that we need to define in the API.

But having done that,
I think that as generally

as part of software development,
we start that,

you know, there's
this whole concept of domain driven design

of being able to model
your problem, understand the key

the problem domain, understand

the, the, the depth of the domain objects
that are involved in that problem domain.

And this is around the ubiquitous language
that everybody should be talking about

what engineers or product or marketing
those domain terms, those domain objects

that define the ubiquitous language
that contribute to solving the problem.

OK, so that kind of

domain approach which you know, you know,
Eric Evans talks about in his book

and the discussion on that happens
in all the churning, the knowledge,

you know this
churning that that happens to

to flesh out
that that ubiquitous language.

I think that then feeds into the API
as a as a resource models.

OK so based on once that that's happening,
it's easier than to just not

thinking of resource models,
which will be, you know,

exposing the API specifications
that are based off of those domain models,

those domain boundaries, those,
you know, context those domain context.

I think that helps that helps
bring out a better API design solution.

Yeah.

So I think for product people listening,
which I hope we get some of those right

since that's kind of the subject
du jour is

I think a lot of product managers
struggle with

how to kind of do that
aspect of design up front

and to sort of grapple
with this reusability thing.

Right.

And not just falling into the trap
of building a one off API

for this particular use case
that doesn't fit into a bigger picture.

So I mean,
do you find in these engagements that

it's kind of a partnership
with sort of engineering and product

to find what that model should look like?

Absolutely.

You know, collaboration is key,
is absolutely key.

And what one of the things

in fact, we adopt in my in my
in my organization, in my company, is

I like a lot
our James Higginbotham ADR method

I think James has been on this episode
as well when he talked about

yeah, he's been on one of these episodes.

So so James has this aligned

defined design refined API design method.

Right.

And one of the things about that
method is, is I like very much

is that the alliance
stage is really about the Y,

you know,
so defining the why defining job. Right.

And then there's the
that's the defined stage.

And then at that point
we're looking at, OK, what are the

how can you break those those those

you know,
high level jobs into into activities

and maybe lower level activities.

And then who are the stakeholders
involved? Right.

And then what are the resources?

And I think that when product
and engineering get,

you know, get around defining those jobs
and then going to that defined stage,

this is where

that collaboration really comes in because
we're defining those resources together.

And of course, a lot of discussion
would happen and it should.

Right.

And we should be ready for the

the fuzziness,
the lack of clarity at this stage

because things are still being refined

things are still being,
but putting things together.

So there's going to be
a lot of discussions

and it should more stakeholders
and more people should be involved

at this stage because one of the things
we want to produce is really

I really like the idea of documenting
a resource model as an artifact for this.

And however we do it, you know, I love
I love markdown.

I love doing it in my town in Git
because I love putting all my API assets

in one repository
and get that's what I do.

But, you know, some people could use,
you know, what documents or they

you have all a complicated software
they use that's fine.

But as long as we document
this resource is someplace

where we can actually plead back
to all the people in the org and say,

what do you think of this resource model?

Does this make sense?

And it's really good to hear

people say, no, no, no, no, no,
that doesn't make sense, right?

Because that's really OK.

So the next question is why?

And that's really what brings up
that kind of, you know, that

that knowledge churning,
that that discussion that happens to

to really flesh out
a solid a more solid resource model.

That's the basis for future extension
of the API on future growth, right?

Because when you have a great resource,
when you have a great resource model,

you can easily extend the API,
you can easily serve other business.

You know, provide
other business capabilities

and, you know,
satisfy that business needs from that.

But when we like that resource model,

it's a problem because,
you know, things get really disjointed.

People find it difficult to communicate.
The language is different.

It's really hard to expand like, oh,
I forgot this other use case and you know,

so so I think that's where problems
can kind of come in.

Do you think there's ever
a chance of too many cooks in the kitchen

and good question.

And I think that that yeah,
there could be.

But one thing

I like is, like in my organization,
we have principal engineers, right?

And this principle engineers
look after domains, domains in our product

and they are really

you know, we use them
as really engineering authorities,

two to two so they help interface
with all the different people

who should be involved
in fleshing out that domain.

Right.

And and they are the go to people who say,

you know, this is
this is what the model should be like.

This is what they and I find it
so it's so important,

especially in my role as an API product
owner to to reach out to them.

Right.

Whenever there's this kind of resource
or domain model, should we use this?

Should we call it this
or should we call it this?

But this is a key resource.
What do we call it?

I find it so useful to reach out to them
because they know how to, you know,

draw the line together and connect
the dots and say, have you spoken to this

or have you consider this solution here
and and really help us

make a, you know, a really good model
so they are people who I see

can Scheppach are really good
at shepherding a good

a coherent solution, good coherent

model that helps API design

and filter out all the unnecessary
opinions that comes in along the way.

Right? Yeah. Yeah.

I'd only add the caveat that sometimes
when you're working with insert

title here,
whoever that guardian of the domain is

that sometimes there's an implementation
focus that can not be the most

customer centric way of describing it
and sometimes needs some translation.

But yeah, I totally agree that that's that
that's that partnership

between product and engineering

so I guess back to your API
ops kind of flow.

So we talked there about kind of value
definition,

the beginnings of this design process
and then I guess from there

we're kind of going build test,
publish, support, all these other things.

You know, what is that
kind of next phase look like for you?

Once we've got sort of a design
coming together?

Yeah, so designs coming together,
you know, we have an API specification,

obviously there's a build,
there's a build phase

coming from that to actually, you know,
build a relevant microservice or services

and then, you know,
exposing that to some some gateways.

But I think 11 key thing
that always comes up with API is it's

how can you check out what fields actually
matches the specification that you

you spent a lot of time
agreeing and discussing and designing.

Right.

And I think that's where

and you know, we have lots of
great tools that help to help

solve that problem.

And we're looking to actually we're doing
lots of work on,

you know, in my company
to to to incorporate those tools.

So so, you know, things like,
you know, obviously

we have a prism from from stoplights
as well is is a good one to that.

That just helps check that.

Look, the implementation
actually matches the agreed schema

and it does it in quite a nice way.

I like it because it's quite thin.

Just sits like a proxy and helps
you do that easy validation

without a lot of heavy lifting.

So I really like that kind of pattern.

So those those tools, those tools help and

and then also building it,
that's obviously,

you know, exposing that fear, you know.

Yeah, yeah.

At the Gateway,

you know, testing it, doing all that,
you know, level one testing,

whether that's functional testing
and other things, exposing it via

if you are a gateway so that the,
you know, the consumer can use.

But the other thing I want to mention
is documentation, because documentation

I think is so important is as important
as the API design.

Right? And it's really modernization.

We have moving that is left as
possible we're trying to get

some of the deck

documentation really early on, you know,
if possible, even at the API design stage

because some of the

documentation we need to write is like
this is how to integrate with the API.

You know, this is, this is,
these are the steps you need to do

or this is, you know, to,
to, to use this API endpoint.

These are
these steps need to do to integrate

but there's this idea that's some
preconditions you should have met.

You know, these are some examples
and it's really good, I think to

and to to try and get some of that stuff

really early on because it really affects
the design as well.

And like my colleague,
one of my colleagues put it this way,

he was like a lot of times
the people who build

the APIs are not the people
who use the API. Right.

And actually they step of trying
to document that API, write some sort of,

you know, API guide, integration guide
or functional documentation,

whatever you call it
actually helps the people building it

get a better feel of what it is
like to use it.

OK, so yeah, getting a bit of that
early on I think helps.

Helps a lot. All right. So better design.

Yeah.

It's funny, by the way,
unprompted plug for PRISM there,

which as a listener knows regularly,
we don't don't ask for the plugs.

But I will say, you
know, it's open source stuff and I think

key way

folks that discover prism suddenly
realize that it is a solved problem.

As much as people think it's
like an impossible thing to figure out.

So definitely worth checking out

on the docs thing though.

I think one it's like two
the product managers, it's

kind of most people
have heard of this notion of like

write the press release
before you build this thing.

Kind of the Amazon methodology.

I think there's some aspect of that here

that is like

if you're forced to think through
how you would describe what it does

and roughly how you use it, you've already
ticked those value boxes pretty heavily

and quite often
in order to see if any of that's possible,

you have to have someone
from the engineering side read

that and go, Yeah,
I think we can do that, or are you nuts?

Right.

So in I think in a lot of ways

it can be a unifying force early
on to just hub around two paragraphs.

What does it do and roughly
how do you use it?

And if you have some kind of spec to go
with it that you can mark against awesome.

Like your level one app, right?

But I completely, wholeheartedly agree.

And the only last bit I would add is
this is kind of stoplight

perspective here a little bit,
but we talked to a lot of people

who come in and say, hey,
we're going to use you for documentation.

Cool. Like API docs are great.

Where are you at?

You know, in your process
they go, Well, we're

just getting ready to launch this thing
and it's time to document it.

And like it's very clear
what's going to happen, right?

This is not going to go well.

This is this not going to be happy people.

They're not going to have a good day.

But when they go well, we're
starting to kind of design our platform

and we're thinking about
how we're going to scale up

designing all these different APIs.

We go there, we go
these folks are going to succeed, right?

That's who we're going to, you know,
really focus our time and energy on

because they're doing it right.

So we see that evidence very clearly.

That stacking docs
on the end of a development process

is just a disaster in the making.

And the customer experience
that comes out the back side of it

is not on the same level.

Yeah, I mean, you know, granted
we'll will help them as best we can.

But I'm just saying, like the notional
evidence is pretty strong for.

Well, what you're suggesting.

Yeah, yeah, totally agree.

I mean, yeah, I can add to that.

Absolutely.

You mentioned support and you know, so far
we've been largely talking

about a lot of engineering ish stuff
that happens between

when some product homework got done
and when we're getting ready

to kind of take this thing out the door.

And there's some tech writers and other
maker types involved that supports

a whole different animal and API support.

I, I feel like maybe the next frontier
beyond API

product management
of how to do API support

because I don't know that
very many organizations have any idea.

So I'm curious, you know,
do you have any secret sauce for us here?

Because I certainly haven't
seen a lot of successful stories

it's an interesting one in my actually in
my actually my previous role

where I was a kind of

what we call developer experience
team leader

at a at a lot OnBase
Consulting FinTech Consultancy

I actually hadn't handled a lot of support

tickets coming in for our
for the as we were building in

and I had the pleasure of of of, you know,

being the one to first respond
to the tickets and first respond to them.

And I think the feedback was just

it was great it was great like

like it like it really focused me
on what we needed to do.

Right?

Like if you expose to the pain
that the consumers were getting

and it really focused

on what we need to do first
and what we need to do next, right?

Like to, to lower the pain
and for the for the consumer

and this comes back to
you know, at the beginning I was thinking

about API ops and first about flow,
but also about feedback, right?

Which is like the second principle is like
how can you get

and build in as many feedback
loops into this value stream, into this

product, this API product development
value stream as much as possible.

How can you get all the
all the other value stream,

all the feedback

to the people who need to get the feedback
right to the to the

to the engineers building,
designing the API,

but also maintaining
and bonding the APIs in production.

Right?

How can we do that?

And, and I think that and obviously
getting, getting the, you know,

the engineering team to, to, to respond to
those support tickets is a great one.

Right?

Because they
they get the feedback straight off

but also but also planning the work
to actually do those fixes.

Right?

In a, you know, quickly
moving in a rapidly growing organization.

There's always a lot more to do than there
are resources to do it like every time.

Right.

And and so there's there's like
there's always like

this is a quick
fix that fixes the problem.

But then then this is the, you know,
the strategic fix or the strategic

solution on how to do it on on
how to you know, solve this properly.

But it's always, always also
especially for me in my role

as an API product owner to,
to, to think about what are the system MC,

you know, what are the system level issues
applying systems thinking here

that would actually stop this problem
from coming up in the first place.

Right.

You know, it's great to fix a problem,

but how can you make sure
it doesn't even come up?

Like, what can you change in your API
design process?

What can you change in your product
discovery process?

You know, to make sure that you don't
even have this problem in the first place.

Right.

And so and so those are the kind of things
I, I spend a lot of time thinking about

an ultimate solutions, you know, Plymouth
trying out new things to make sure that

not that those kind of things

don't happen.

The other thing
which I quickly mention on as well

is like I really think and this is
one of the things I'm really putting

a lot of work into myself, trying to put
a lot of work and resources into

is really to really start
capturing metrics around

those API related defects
and how you, you know, categorize them.

Is it just a documentation defect?

Is it a, you know,
or is it like an API or some other defect

or the API is actually failing
in production and gathering

all those metrics
in a place that it's visible

and for the relevant people to see it,
you know, because part of this

just makes making some of the stuff
visible.

OK, it's a good start right
to solving the problem.

So, so making
sure we're building in enough

I know
a we use it to observe observability

to talk about the actual running software
and getting metrics on the software.

But but what about all the things
that are very specific to the APIs

and making sure they're good
and making those that information,

those metrics available to,
to the people who can make sure, you know,

they're fix
and we don't have those problems again.

So we're really interested in those. Yeah.

Yeah.

And not just locked behind a support
ticket software right where it's

gated to only the support team members
being able to see it surfacing.

It is absolutely crucial.

Yeah well it can I feel like we
we ran the whole gamut.

I mean, we ran through the whole lifecycle
and kind of I think you win the prize

because we always end up

going down one particular rabbit hole, but
we actually went kind of end to end on.

I mean, we skipped deprecate,
but that's just sad.

So let's not do that today.

But when you kind of reflect
on, you know, this

kind of lifecycle, this API ops,
whatever you want to call it,

for some listeners who maybe aren't doing
many of these things today

and they might be a little overwhelmed,
like that's a lot of stuff, right?

Yeah.

What do you think is, you know,

your first priority,
where would you get started

if you give someone
kind of a recommendation

on, hey,
if you're not doing any of these things,

what's the most important thing
to get going first?

Yeah, yeah.

Thanks, Jason. For me, it will be

for me to be to listen, actually,
just just listen.

Right?

So when I joined my roll out at ten X,
one of the things I did was just,

just listening on the,
on, on, on my teams.

Just stand ups, listened to what
the pains were, what the constraints are.

Listen to this story.

Refinement meetings
have one on ones with people.

Catch up and see what problems do you see?

What problems did you want most solve
right and I you know,

get into our API gills an API guild's

internal API come to
your practice is a great way to listen

to what pains other people are facing
right relating to API.

So so just listen to see
and what other challenges

people have OK and listen across
listen across.

We used to have these standards meetings
where we create these I standards.

Again, I'll just listen
and try and find out and when I do paints

OK because I find
that's a good place to start.

I like like solving the solving
the most crucial pain

and that actually buys us time
and capacity to tackle the bigger things.

Right?

And so, so I like, I like, I just like
listening and documenting those things.

And then and then

that's almost like an internal problem
definition, if you like.

Right?

Capturing those things
and then and then discussing about, OK,

how can we approach this things?

Because once we know like

this is the biggest problem
and this is a second, this is the third

that's already defined like a roadmap,
if you like, or like

kind of a priority list

and basically working through working
through those because, you know, there are

there are loads of great tools out there,
lots of great books.

Lots of this stuff is there. Right.

But sometimes it can be a bit overwhelming
if you don't know where to start

and part of part
of knowing where to start, it's just

it's just for me listening and solving
what the biggest problems are

and attacking those ones first. Yeah,

I really occasionally have the thought
we should get a T shirt

for the API Intersection podcast
that just says empathy across the front.

Right? This is the same thing right here.

You want to do developer experience,
you got to have an empathetic approach

you got to be a decent listener
and and solve what hurts

because sometimes it's not as predictable
as it seems.

And all the other process stuff
you can just sat on this, you go,

Yeah, but yeah,
I love the message of empathy.

It's, it's the thing
we hear over and over again.

I'm here so

well, that feels like a great place
to wrap.

Really appreciate this again,
a tremendous amount of knowledge.

And I think, you know,

again, you're our people.

You're in our wheelhouse.

So you're welcome back anytime.

OK, thank you, Jason.

Thank you, Anna.

And great being here.

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.