Subscribe
Share
Share
Embed
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.
API Intersection Podcast listeners
are invited to sign up for Stoplight
and save up to $650
is the code INTERSECTION10
to get 10% off a new subscription
to Stoplight Platform Starter or Pro.
Take a look at this episode's description
for more details.
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.
Sometimes I say, you know, we're going
to do something a little different today.
Seems like the thing
I always end up saying
at the beginning of these
and I guess it's kind of true today.
Still API stuff though.
So first off, I'd like to welcome
our guest, Marjukka Niinioja,
I think I got that right.
Did I get it right? Yeah.
All right.
From Osango.
She's a co-founder there. And my...
I guess
tell us a little bit about yourself.
My general sense is you guys do
some sort of consulting stuff, but
tell me more about what we do,
Some sort of like I think you've heard
about APIs consulting.
We actually do some API business
consulting.
So we end up doing
a lot of architectural stuff too.
And recently information
architecture
auditing has been a trend for some reason.
But APIs, API, business
models, API ecosystems,
anything to do with APIs like Iot?
A lot of stuff like that
and also training.
Got it.
What's the typical customer
look like for you?
You know, perhaps in sort of a size scale,
whatever?
Yeah, that's a very interesting question
because when we set up the company,
we kind of thought
that the typical customer
would be a fast company
or something to do with software.
And that was where we started.
And one of our first customers
was actually from U.S.
of Com, which was kind of interesting,
but then it started evolving.
So we did a lot of public sector work
and nowadays
we are doing a lot of like building
construction, farming
and banking and a variety of other things
related stuff,
which is actually like really,
really large global companies.
So it's super interesting and we're
working as part of the eco collective.
So we have friends and colleagues around
the world, which is even more exciting.
Yeah, I feel like at
Stoplight we've had kind of a recognition
thing over the last couple of years
that it's like it used to be
if you're talking to somebody about APIs,
it's some kind of, you know, at
its core a software company.
And these days it's like,
you know, our top customers
sell beer and electrical parts and
got all kinds of just in dust
real stuff, right?
So it's it's easy to forget
that APIs are everything everywhere
all over the world now.
So yeah it's I feel like
when I sometimes think in my head, like,
what if I went to consulting right now?
It's like, man,
you learn so much about so many different
things that you wouldn't expect.
Exactly.
I spend some funny times
kind of using everything I knew
about electricity
and kind of like four days
each to how some
big bulky electricity
thingy is work
that are out there and stuff.
So, I mean, like you really need to know,
but also learn about a lot of domains.
Yeah.
You mentioned
that a lot of folks are doing
I forget the phrase that is, but sort of
sounded like domain language
audit or something.
Well, yeah, I mean, sometimes
people are kind of
we are doing actual information
architecture
or which is actually it talk
to use the term domain, of course.
But it's an interesting thing
because we are partnering with some
some really great design companies.
For example, when they are now
designing these cool experiences and
awesome visions.
But then of course, there is that reality
check sometimes that you have to do.
And, and in UX, you're,
you're used to having information
architecture, but it means kind of
how things are structured on the web
page or taxonomy is on things like this.
So what turns on is now you could
you really need that kind of approach
also with API design a lot of times,
but actually you
do need also kind of information
architecture from the point of view
of enterprise architecture
kind of glasses.
So there are lots of things that
you actually need to tie these kind of
tie all kinds of design activities,
commercial design, UX design,
different architecture designs around.
And recently actually, we have been
working with framework for for kind of
how to this
sounds like,
but how to purchase Iot platforms
because the thing is that
it's a domain of it's on its own,
but of course
it's connected
with different business domains
and everybody seems to have
some kind of different ideas.
What isn't Iot flatterer, how it works.
And of course it does
have also a lot of things to do with APIs.
So I think that you could say that
that we and probably some others out
there are also working in this kind of
interface between different
kind of roles and and domains,
but also different silos in the companies.
Yeah,
certainly in my own experience,
but heavily validated here on the podcast,
it's been really fascinating
to see how often people say like,
you know, the hard part
is this sort of alignment of language.
So we tend to it's like you'll hear
vocabulary or grammar or,
you know, different
kind of ways to describe it.
But ultimately, if you don't know how to
talk about the things that you have,
you can't design anything much less core,
you know, core functionality
built into your backend services
kind of spreads and leaks out everywhere.
And if you don't get it right.
Yeah, that's right.
And I enjoy it because actually
my background is as I'm ah,
I studied education in university
and operational sciences
and also linguistic sciences.
And it's really, really interesting
because then you understand
that what people say
might mean totally different things
to different people, but that's not often
what people kind of
in the business context think.
So they think if somebody uses some word,
it must mean the same thing
as I'm expecting it to mean.
And that causes a lot of confusion.
And that's actually why, I mean,
probably are going to talk about this
method in cycles today.
But I actually created that
method originally to solve that problem
because I found that
the biggest problem was that people
from like design or product
or architecture
or different parts of I.T and developers,
they were not just using different words
or like the same words or different
things like validation for designer
is a different thing than validation
for a coder. Just
so so
not only they were using different words
or same words,
but but they were having different methods
and different ways of describing things
and it caused a ton of confusion
or things just were not moving.
So an average API developing team
was just not as productive
as it actually could be
and is not as productive as they could be
because of these reasons.
Yeah, I was I was kind of
snickering to myself over here
because I think of my past experiences
with words like metadata.
I don't I have no idea what that word
means anymore, because every domain wants
to have a metadata thing and every time
it's there or is meaningless.
Yeah.
Yeah.
So I feel you on this one.
That's funny.
I think in some ways
we should almost be talking about APIs
in terms of their usage internally,
perhaps
in sort of microservices and other things
as almost a communication tool.
Yes, almost more importantly
than a technology tool.
Yeah. Yeah.
But it only works if people kind of Well,
I, I hate this conversation
going into that kind of
either taxonomy or glossary or whatever
vocabulary discussion, our domain models,
I mean, that's one part of it.
And yes, you can standardize it,
but it's only one part.
One thing is that it's kind of like
it's not just talking,
but it's like requesting from another team
something that, you know,
I use usually, often need this thing.
Can you make sure I always get this thing
I want and I don't need to explain
a lot of stuff.
Like if you every time, every day you're
you wanted to have a cup of cup of coffee
from the nearby shop
and you have to explain them in detail
what kind of cup of coffee you want.
That would be really, really annoying.
Instead, you go there and the guy there
probably knows you
already and you're exactly,
you know, the Ryder Cup of coffee.
And so that's
that is the experience even from the APIs.
So that well, I think
perhaps something you're
not explicitly saying but is implicit
is that having a customer centric view
of how you describe things. Yes.
I mean, you're speaking in customer
language.
Is it is it's sort of an invisible level
up for an organization
to not have to quibble
about the meaning of things.
And when you turn around
and talk to the customer,
you're not confusing them, but things
they have never heard of either.
Yeah, but actually that's exactly
the in-built thing in cycles.
So for example, today I've done a workshop
with some Australian customers
and I just came here
to record the podcast from a session
with some students, university students.
And in both sessions
we were using this concept called value
Proposition API value proposition
canvas from of cycles.
Mm hmm. And,
and all those canvases in it.
But but specifically
that economists are meant
for you to kind of interview or think
from the customer perspective,
from the API consumer perspective,
and then kind of map out
the pains and gains and their needs
and then start thinking,
okay, what kind of features
we want to provide to these needs?
Do we want to provide anything
or do we want to provide something else?
And all the canvasses of those,
for example, data requirements Canvas,
which is meant to be a tool
where people who don't necessarily know
anything about APIs and just say,
okay, these I think are the important
terms or important words in this context.
And these are the questions I would like
to ask, for example, from that.
So so the idea is that you can do
kind of basically the whole design
of the API interface,
but also the business model
and the kind of product market fit
and even find any reusable API
or any new address that you're missing
with those canvases
without actually knowing anything
or not very much technical stuff.
And the insight from, for example, the
Australian customer this morning was that
we really
should have had more business people
in that group than we had
because then we could have really
had the right conversation.
And that's what we keep telling people,
that you do not use
these tools and these cameras
and this method alone.
This is not the I'm an architect.
I go to my kind of books
and I draw some diagrams
and then I come out
and everybody just magically understands
what this thing is supposed to do.
But it is a collaboration
and a communication tool,
and it's a tool to get fighting.
You know, anything around, it's like,
what do we really, really want to do?
Yeah, yeah, that's that's definitely
something we've heard a lot of, too.
And I think we've seen it
in practical trends, certainly with stop
by customers to is that this
the sort of historical perspective,
it's like APIs are designed by
or APIs are implemented
by engineers as a, an implementation
detail of some broader thing.
And that
means that you end up with an engineer.
Does an engineer add
experience as well, or
as opposed to what we keep seeing more
and more of is like product
managers and folks
closer to the business side
are taking an elevated role
in that API design process.
And really the engineering folks
are there to sort of
call out this practical,
you know, real world
constraints that might hold you back from
having the optimal model or something.
But that sort of locus of control
of of design of the asset.
Right, is changing. And a good one.
And it's kind of it's
I know this blows up some thinking
that you have traditionally come to think
if you are an enterprise architect,
information architect
or somebody that you know
if you have certain like let's
say a Colin's products or something,
you know common that you can actually have
multiple different APIs for different
with different value props
for different use
IT users and segments of API consumers
are using that same account
and it's still okay.
It's not going to, you know, destroy
your data management or do something bad.
But on the other hand, I loved it.
We had a really kind of hectic session
last week with a
with a big energy company,
and they were really kind of like
there was this whole business
focused team thinking of
what are we going to do with our APIs?
And they were asking, Well,
like as the last question,
what API should we be building?
Like, okay, nice question.
After like 50 minutes, how do you guys
really kind of write down?
So is like look for problems?
What are your customers and partners
kind of complaining about?
What are you complaining about?
Those would be probably very good
candidates to start with
from a kind of design thinking mindset.
Yeah, it's
for better or worse,
I find that the process of people going
we need an API strategy quite often
sort of shines a light on the fact
that there isn't a real business strategy
and people are just being reactive
and it can kind of lead into Yeah,
but the API is just a tool
to connect things
like what are you trying to accomplish
as a business?
Exactly.
And I think for folks that lean into it,
it really opens up
all the right discussions.
But quite often
that's where things go sideways.
Certainly.
Yeah, I mean, it
it really depends who you are talking to.
Like who's your customer,
who are you talking about?
Because of course, if the discussions
are on the kind of wrong
level of the organization
or on the part of the organization,
and there is no way for that part
of the organization to communicate
about a potent commercial change
in business
strategy,
then it might be leading to problems.
And we've seen that kind of happening
in a few cases, but we try to avoid it.
We try to make sure that that doesn't
happen, for example, before we start with
new customers.
But I was talking with
a senior CIO
and he was really, really great.
But once he understood that we might need
to talk to business about,
you know, these APIs
and the strategy around it, you're like,
Oh my God, but I can't, you know,
because if I buy you in,
then that's going to create problems
because I can't touch business.
So yeah,
we should get rid of that problem.
Yeah, I don't know.
I mean,
this probably is its own rabbit hole,
but I think my experience has been
that a lot of times there's tremendous
information and compartmentalization
and kind of a fear of overexposing
business strategy.
That means that
nobody really knows what it is yet,
which I feel like,
you know, you go like, Well,
yeah, but if nobody knows
and doesn't really exist.
Yeah.
So look, you've hinted, I think, you know,
we talked to practitioner types,
you know, working on a program
at a specific product
or company and we hear this sort of thing
and you go, Well, how do you do all this?
And they go, Just get the right people
and get them in a room and a market board
to figure it out.
I think what I always enjoy about,
you know, and there's frankly
not a lot of sort of folks that do this
sort of strategic API consulting.
But I love is the
the once you've gone through that pain,
once you want a repeatable method,
you want something that guides people
through it.
And you've kind of hinted at this API
ops cycles thing. Yes.
So tell me more about it.
I'm fascinated, actually.
Yeah, it's it kind of was born
because I was having problems or rather
I was being successful.
But everybody kept asking me,
how did you guys do it?
I was like, I have no idea.
And then I kind of pulled back
and I was like, okay, I'm
I'm supposed to be a master of education.
I must able to crack this top.
And then I was like, okay,
there are some people talking about
like API business, road cameras,
but that's it.
There's nothing around it.
And at the same time
you're actually doing a lot of product
management related meet up,
something like that.
So I started thinking, okay, what are the
things that businesses are using already
and what is the kind of methodology
and who are talking?
I'm using which methods.
I was like, okay, if we can pull these
together, like product management
designers, architects, developers,
everybody who wants to make things
more efficient, so lean on
Lean was kind of connected anyway
with DevOps and API ops and everything.
So so it kind of turned out to be a method
and it's it's openly licensed
so anybody can use it.
And, and
at first I was like, Hmm,
maybe this will work.
We actually started trying it out
with a big industrial company
and it kind of worked.
So then it started
just going around the robot.
I thought that, well,
maybe some people you saw
last year, when I looked at the stats
in December, I was like, Oh my gosh,
they're like companies around the
like all the world using it so good.
But we also did a big overhaul
of what you can use it for is is
of course just designing one API, copy it.
That's totally fine.
It leads you
from that initial idea of an API to
kind of customer
needs to the actual implementation,
then putting it, publishing the API
and things like that.
Originally, one of the reasons it was
created was also I was in charge with a
quite big retail
company and the API management
platform enrollment there.
And the problem
was that everybody kept pushing
invalid
APIs like they were pretty horrible, but
they might even have done them
according to some standards and tools.
But they still didn't
pass the validations, They didn't work.
So we needed some checklist of like,
this is what you should be doing.
And so in the method,
there's also this API audit checklist,
which is quite versatile.
You can use it if you're buying APIs
or if you are building or designing API.
And that's actually the most common thing
that people are using from it.
So but you can also start building
your strategy using the method.
So you just take a little bit
of a more overview look and you take,
you scope an area of the business
and you start using it.
So for example, today
we've just been using it
for exactly that purpose with a client.
Yeah. What I was fascinated by is that
and it's funny because like these days
people go, you know,
API first, like, are you doing API first?
It's kind of like when,
when Fowler came up with the microservices
term, is this a microservice or is
is it micro?
And it was like a five year
discussion, right?
Yeah,
but sort of following
the steps that are outlined here,
I like that it's business
first and using this sort of canvas,
which I mean,
I don't know, for me just like something
like a Miro does a pretty good job.
It just, you know, boxes and lines can go
a long way as to getting basic alignment.
But like, what is this sort of canvas
look like in your optimum setup?
Well, it's basically very simple.
So it has well,
first of all, there are several canvases.
So there is a kind of
set that you can follow and be happy.
A lot of companies use this API value
proposition canvas on them.
The business model canvas hot tip
do not just use the business model canvas.
You will get much easier life
if you start with them all.
You can was first.
And it's just, you know,
there are some simple guidelines on boxes
and there is a structure
of how you should do it
and there are detailed instructions
to offer it.
And there is even like in our song
Academy, there was even a two hour course
on how to use it with videos, me
explaining the whole thing.
So it's it's really kind of
it takes usually people are
first time,
maybe one and a half hours
to start with the lollipop economists
because they need to get their hands
around it and understand the product
thinking and a lot of other things.
But once they've done it
one time, it's usually like
30 minutes
to 45 minutes with the next session
and it gets like faster and faster.
So we've had university students
who have never heard the word API before
and after they have been introduced
to customer journeys
and a few other things,
they actually can make an API value prop
canvas in one hour and come up with
some really decent results out of it.
So it's that easy.
Yeah, that's what's interesting
too is like you mentioned that you sort of
had an educational background
and I noticed you had a kind
of a lot of things pointing at sort of,
you know, student resources almost.
So is this something that you've actually
got sort of university connections
going with?
Yeah, Yeah.
So we have already like a couple of years
back, we've been
having this online course,
which is actually free open university
course and also going to meet
with a university from Finland
Introduction to API Economy.
And then we have an introduction
to data economy with another university.
And then this
course that I was talking right
now is actually more hands on.
So it's a remote course are called
featured me
which we actually set up with Cisco on
a Finnish university
and and and also the introduction to
API economy course was actually later
funded more with by connect
which is a Finnish originating
elevator company
globally and they wanted to translate it
into Mandarin, Chinese and German
because they wanted to educate
their customers and partners.
And those are also available for free.
Very cool.
Going down the sort of, you know,
numbered list of things in this approach.
And you had mentioned it earlier
that the API audit was kind of a big thing
and you know, certainly in my
my world of always trying to think about,
you know, design before implementation,
it's like the sort
of, you know, design review process
stuff is always front of mind.
But this kind of reads like more of,
you know, you already have stuff
and you need to understand what it is.
Yeah, well we divided it actually
in the new version to three parts.
So there is like the first that we tease
for the design,
the thing is that a lot of people,
especially developers,
they don't think they make bad APIs
until they see some list.
That is,
these are the things that a good API has.
So and then again, the bigger
the organization,
the more likely it is
that they have a ton of conference pages
guiding how you should do beautiful APIs
and nobody ever them
honestly, because they don't know
they should because they are making this
nice API anyway.
So the checklist was
basically an attempt
which has worked quite nicely
to cut away 100 conference pages
at first
and actually get rid of design reviews.
I'm sorry to say this, but combined
with your wonderful stoplight
and this was not a paid commercial,
but kind of like combined
with the automation that you can get
to reviewers and write APIs
with this kind of like these are
the things that you actually need
to think first and really design
and you can't really automate them.
So so with that,
the checklist approach is quite powerful
and ah, and also some,
some companies, our customers,
but some others are also
starting to do
this kind of metrics around API design,
for example,
how many good APIs we have, for example.
So those kind of things like checklists
on automated audits can help,
but the automated
audits can only help with
the open API
or other kind of really fact based things.
Yeah, I mean, by the way,
I'm kind of with you as much as we are
always like, you know, if you're not doing
some kind of design review,
it's probably a bad thing.
I think maybe what you're saying
is like the nature of that
review should be more
sort of
let's discuss the functionality
and how it fits in the bigger picture.
Not doing this API, do you. Yeah.
Like,
you know, specially with like spectral
and I mean even beyond stop light.
Like there's plenty of tools out there
to take the boring stuff and automate it
and don't talk about it, right?
Just make it green.
Yeah.
Discuss it once, write a rule
and then never talk about it again.
Right.
So I think as longer design review is like
existential, like,
why does this thing exist?
How does it fit into the big picture
as opposed to, you know,
it's supposed to be dashes here
and not underscores?
That's a waste.
And the thing is,
you can't have an intelligent discussion
on the existential reason for the API.
If your team is really not in the right
level of maturity to even,
you know, like I told somebody,
an organization was spending like 2 hours
with every iteration of every API
and everybody was really frustrated
because the junior developers
or developers who were not
who were New York, three guys,
they came to the reviews
and they were like, just my API.
And then they were first ask
like all those existential
discussions and questions
and they had no clue.
And then when you look at their API
design,
it's like you don't have any status codes,
You have this and this thing wrong.
Like if I'm just looking
for your first endpoint,
why would somebody spent hours
reviewing this stuff?
Because you can immediately
see that there are a lot of things missing
because this junior doesn't
necessarily know
or they have been doing some other kinds
of APIs or some other kind of software.
They are just new to APIs.
So first, solve that problem,
then take that to the next level.
It's like Maslow's
Hierarchy of Needs, basically.
Yeah, I like that you broke down
like this, this notion of sort of review
or readiness is different of each stage.
So like they're sort of prototype,
then design and then production.
Yeah, it's like that different level
of concerns at those different stages.
That makes a lot of sense in
terms of being iterative
and getting the important stuff upfront
and then all the little niggly things
when you get closer to production
and it's kind of also the whole thing
is tend to kind of
have these lean principles in the message.
So flowing in is of course
a management method,
but the, the DevOps
thinking Kanban for example,
is very much based on thinking,
even if people know that.
But but the thing is
you're trying to reduce waste.
And this whole thing
about I said about the design reviews,
there's there was a ton of waste
because you were trying to review
all the things from something that was
not meeting even the first criteria.
Why would you do that?
But on the other hand, why would you even
review the first things?
Because you could take care of that.
The developers
actually know what the first things are
and that they concentrate on those.
So there is this kind of
concept of eight wastes of lean
that is being talked about a lot
in Lean management literature, and
there are all these kinds of wastes
that are usually related to either
too much stuff being made or waiting time
or people needing to kind of chomp around
to complete their tasks.
And on a very many other things. And
this is kind of the point of the method.
So how to reduce the jumping around
the waiting are the general lead time.
So the time that it takes to complete
things,
an API and also kind of reduce
the time
that people try to understand each other
and try to understand the guidelines
and things like that.
And and also kind of taking and reducing
the unskilled work in a way.
So I think if it really is
even even though
lean management might not be the developer
kind of management skills of the year,
but I mean
it's really an important concept
because I mean customers or management
or whoever is always complaining anyway
about why are you taking on as much time?
Sometimes some teams take years
to complete one API.
Honestly. Yeah. Yeah, for sure.
Yeah.
It's funny, I spent a number of years
in the manufacturing business and did like
all the lean things like read all
the books, did all the management training
up to
and including like Kaizen workshops, right
where you're standing around
with stopwatches, recording time on
how long it takes
someone to pass a box to the next person.
But when I think it
instantly resonated for me,
one that it is a business
centric set of concepts.
That means you can engage folks
outside of engineering,
which is in a lot of places,
the big first challenge,
and two, that it's practical enough
that if you went, hey, here's
an example of what Lean looks like,
you know,
like in my experience, you know,
you go into the shipping department
and it takes, you know, X amount of time
to get a box to the shipping department.
And if we can cut that down by 60%,
then we've made everyone more productive.
They're wasting less time on menial tasks.
That's that's always going to resonate
with developer types of,
hey, you know, we're we're incentivized
to be lazy, right?
Like make it easy for me. Yeah.
And everybody's bored
waiting for the requirements up.
Never come or Yeah, an architect
trying to explain, you know,
I have these boxes and arrows here
and then the developer is like,
where's my sequence?
I know what I who I come by just,
you know, to use my notepad.
I designed an API so.
So I mean, there's a lot of waste time,
but I've found that a lot of products,
product managers, product
owners, product managers, for example,
are also kind of excited
from that point because they are
expected to deliver
and they can't work
if they don't even know
what the team is supposed to do
to deliver.
A no.
It makes sense though,
to to apply that sense of
look at the throughput of the whole system
and find the sort of critical.
Yeah, that the critical chain right.
Like what's the quite often it's
like one or two steps in your
overall process
that are eating up all your throughput.
So to look at the process of
what does it take from
the point that someone thinks
they need an API and, and and it
and you know
does it even fit into business strategy
like all those things can bogged down
before
before you even get into development.
I mean a lot of times
they try to governments easy these days.
There's so many good tools,
but it's all the stuff around it
that eats everything up.
So yeah, it's actually funny
that we've actually don't.
I mean, this would be a place for,
you know, some scientific research, but
people actually, if they are given
a task that, you know,
think of what APIs should we actually
build based on this business case
or whatever topic.
And if they list at that moment,
the API that they think should be built
and if they look at the list of APIs
that they should build after doing it
with the multiple panels on the even
just the value programs,
it actually is a very different list.
I mean, of course
there are some similarities, but often
it looks really different.
And the biggest waste is that you build
something that is big and beautiful
and has all the
attributes and massive amount
of endpoints or whatever,
but it doesn't do what your customers and
partners on your colleagues or whatever
wanting you to do.
And this is actually an interesting thing
because a lot of times our customers
now are kind of either they're
massive regulated companies
who are used to delivering
like really slow motion
software compared to the SaaS
or or kind of startup world.
And but the startups need to use the APIs
provided by these big companies.
And sometimes they are really,
really complicated partnership relations
because, you know, you promised this
feature for us, you know,
three months ago or three years ago
and we still haven't received it.
What case.
So there really needs to be
this kind of meadowland.
And we've had these kind of
really good conversations on things around
these kinds of problems with this method
because it makes sense to both parties
slightly for different reasons,
but still the ability to deliver
is the big thing
that I feel like
sometimes people want to slap me
when I just tell them simply
like one Don't forget it's a product.
Treat it like any other products, right?
Do all the same homework.
And to this is a design exercise.
And if you just a group of designers
and said here's my requirements, build it
they didn't do any research,
they didn't talk to any customers,
it's going to be subpar. Right?
And the same applies
when you're designing this back
end service that maybe no one's
ever going to connect with externally.
Yeah,
but the problem
there is that a lot of times
people, you know, that are designing APIs
or are designing the architecture
that has APIs are not product management
professionals
or service design or whatever it is.
And and that is actually
the biggest hurdle
sometimes that some some people
and some companies and some teams
in starting to use the value prop cameras
on other things
in the API assignments because first
you actually need to teach them
what is the meaning of product management
and product thinking.
I've never
specifically
use like the value canvas thing,
but I think the same sentiment applies
in these sort of workshop environments.
I always tell folks
if we if if we invited a group
of customers to say a feedback forum
or something like that
and we put this on the wall,
but they go, yes, that's my things.
This makes sense, right?
If you can't pass that test,
then you're doing it wrong.
Yeah,
yeah. Validation is really important.
Cool.
Well, I could do this all day,
but people won't listen.
Probably passed about 10 minutes ago.
We're probably over time
as it is for attention spans.
But I really.
You bringing all this to us?
And I definitely personally have not.
I've seen this but not paid attention.
And now I'm like ready to dive in
So I really appreciate it.
Sounds nice.
Thank you for inviting me here.
No worries.
Any other closing thoughts or sort of
things that you want to share
with the listeners here?
Well,
I think we
basically said so, Yeah, that's fair.
You should just dive
into all the material, maybe
take a course or something.
And by the way, there is a the eight waste
offline e-book is in those on market.
I mean,
do you come up and roll their stories?
Yeah.
And I, as always, will have the blog post
that accompanies
this that has all the links in it.
So be sure to check that out.
Thanks again,
Mark, and really nice talking to.
Thank you.
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.