Growth Stage by FastSpring

Hello everyone, welcome to Growth Stage, where we discuss how digital product companies
can increase the value of their business.

I'm your host, David Vogelpohl I support the digital product community as part of my role
at FastSpring, and I love to bring the best of the community to you here on Growth Stage.

In today's episode, we're going be talking about tips for adopting agentic engineering.

No vibe coding here.

And joining us for that conversation is the Chief Product and Technology Officer of
FastSpring Chris Bunk.

Chris, welcome to Growth Stage.

Thanks a lot, David.

Great to be here.

Awesome.

Is this your first episode on Growth Stage?

I actually don't recall.

It is, as a matter of fact, and uh I'm excited to speak with you today.

Excellent, excellent.

I know you've done some other podcasts since you've joined here.

Um, but what for those watching and listening, what we're going to be talking about today
are Chris's thoughts, having spent the last few years diving into the deep end of agentic

engineering, and he'll share his thoughts on the difference of agentic development versus
engineering.

What is the difference there?

Uh, where we're at, and where we're going with agentic engineering.

So if you're wondering,

how you're gonna scale uh agentic engineering within your own org, or maybe you're kind of
just getting started, or maybe you're far along.

Hopefully, you'll get some insights today that'll help you with that journey.

So, Chris, the first question I have for you is kind of a twist.

I normally ask people what was the first thing they bought online, but I want to ask you a
slightly different version of this.

What was the first AI product you spent your own money on?

That would be when Chat GPT first came out, was the first time I actually forked over
money to open AI to be able to go get the uh Pro Plan, I think it was called back then.

Uh to be able to go and essentially get more tokens in the latest models to be able to go
build stuff.

It uh I had read a bunch of stuff and I had kind of at the time I was a little skeptical
that LLMs were gonna be anywhere near to where they are today.

And that was really the unlock moment for me where I was like, my gosh, this is if it
could do this, I could see where it's gonna go, where it's gonna evolve.

And um and I was I was almost a little obsessed at it when it first came out.

I was spending like my wife's like, What are you doing?

Spending your nights and weekends on this, come on.

But it was just fascinating to be able to go in and have it have it build code and it was
so far worse at it than it is today.

It's almost it's funny to think back on it, but

Um but yeah, that was my first product that I I picked up and well worth the investment.

That's cool.

Yeah, I remember buying the pro plan pretty quickly when uh playing around with GPT and it
was so cheap.

And I I'm not sure where it is today, but I remember that it was like the twenty dollar
plan.

Was there a particular roadblock that got you to spend over the free plan?

Or was it just, you know, relatively cheap?

So like why not get the pro plan?

The uh both the newer model and the amount of tokens were both like constraining factors
that required.

I'm pretty sure there was a constraint on tokens even back then uh associated with it.

And the other thing too is pretty quickly after Chat GPT I pulled the trigger on paid
Cursor uh subscriptions and then Windsurf subscriptions.

And these are still the early days when it was j these tools were just hitting and
becoming

No, yeah, that makes a lot of sense.

I do remember wanting to get access to the newer models as one of the motivators for me
personally.

And it's funny you mention this idea of quality improving, and it's improving so fast too.

It feels like in the early days it was making tons and tons and tons of mistakes, and it
really wasn't ready for proper development and engineering teams, but it's just been so,

so fast.

And so I think it's very interesting to think about where we're at.

And to get a fresh point of view and kind of these touchstones along the way, just so
people kind of get a feel for what's happening and can take advantage of that in their own

organizations.

So one of the things, um, at least pre-AI, we talk a lot about is what is a developer or
an engineer, or in in some worlds we've called assemblers, people who kind of piece

together technologies to to make products.

in in like this different level of sophistication.

And and so now with AI, we have uh abstracted out some of some of that and and it kind of
changed, I'll use a corporate buzzword, but the paradigm, if you will, of what all this

means.

But I'm kind of curious, um, with where we're at now, what it how do you view the
difference between like agentic development versus engineering?

and are both vibe coding or neither vibe coding?

Like how do you think of the uh the language there and the terminology?

Sure.

So first off, I just want to acknowledge that a lot of these terms are fresh, hot off the
presses, not like some formal standards body or dictionary company coming in with precise

definitions on them.

So I'm gonna answer this in terms of how I think about these words, um and and what they
mean, uh as best as I can associated with this, but there's no like official standard

associated with it.

So with that disclaimer, uh starting off with

when I hear people say agentic development, it's pretty cl uh like it's kind of like the
narrower focus on when it actually comes time to write code, uh, against, you know,

something you need to go build.

It's that narrow portion of the life cycle where you're like using agents to be able to go
build code associated with it.

And there's, you know, like over things have evolved a bit and like kind of almost think
of them in terms of levels of maturity of of of approaches to that.

But there was like

The early days where you have auto completion, um, you know, with Copilot was like the
first one to come out with that kind of stuff.

And then you had the the Cursors, the Windsurfs, there's a bunch of other tools in that
class.

And they were like where you had your classic IDE set up, but you had a window that could
open up on the side, you could talk to it and it would go in and you know, crawl across

your code base and like fully change files.

But then you could also, depending on what mode it's in, like tab through the suggestions.

So you kind of were still very

looking at every line of code, hands-on, um, you know, building that out accordingly.

Um, when I think about agentic engineering, you know, as opposed to development, I suppose
that would mean a more broader viewpoint.

I would say a more comprehensive look at the software development lifecycle.

There's even a term that gets kicked around that I like called the agentic development
life cycle.

And I think that would that kind of gives a nod to the classic software development
lifecycle.

You might want to

A different one in parallel for agentic development, or at least it's evolved and changed
quite a bit.

But you can use agents and agentic development for everything from, you know, ideation,
product discovery, and all the facets of product discovery, you know, of course the actual

development, code reviews associated with it, verification and validation, like really the
whole life cycle, every single thing that we traditionally do to be able to go build

product in a project engineer product engineering team is something that we can go in and
think.

Back to first principles, what's the right way to do this on a with agents, basically
associated with it.

Um, getting to your third word there, vibe coding.

It's funny, I have different feelings on this.

And so first off, it's the original uh Karpathy uh I always mispronounced his name.

I hope that's it, definition of it when he first coined it.

And that was um that it's basically you have an idea of what you want.

You ask for it.

You're completely black boxing the code.

You're not directing architecture.

You know, you're basically just saying, Hey, go in and give me this feature or make this
faster or go in and change this behavior.

And you're just telling it and then you validate with a human in the loop and go, okay,
that's not quite what I wanted, or hey, this has a bug in it.

Go fix the bug.

You keep iterating and you do it that way.

It's very largely black box.

To do vibe coding, you don't need to have a uh, you know.

uh in a strong engineering kind of sense to it uh with it.

And and vibe coding is also like a thing that I consider on the spectrum of how much vibe
coding you do or not do uh associated with it.

And so um, you know, we could in this case consider vibe coding to be pretty far end of
the pure end of the vibe coding end of the spectrum, but it's really easy to just

introduce additional stuff with vibe coding to mitigate a lot of the downsides associated
with it.

I will say that vibe coding is not fit for uh like true enterprise grade products and
engineering associated with it.

And so um, you know, you really need to be deliberate uh about how you set up your agents,
about how you drive architecture and be aware of the architecture, how you drive the kind

of product flow and narrative as well too, so that

You know, you truly can understand it as one of the practitioners building that kind of
stuff out associated with it.

So if I'm like I'm not a developer or an engineer, but I'm using uh agents basically to
create software for my own personal use, like custom Chrome extensions or something like

that.

And so that's maybe more vibe coding, where like it's solving a problem, I'm the human in
the loop validating that it's doing the job to be done, but I'm not an expert.

And so I'm not gonna be able to get it really in a state where it's ready for production
and and like mass distribution and things like that.

And so maybe maybe that's a way.

And and it's funny because you you mentioned human in the loop.

And one of the things I've been thinking about recently is that really expert in the loop
is where you unlock a lot of value because obviously the agents can help you move fast,

but without the expertise to validate what's happening and to direct and orchestrate it,
you're really not producing anything of like super high quality, or at least again,

something like production ready.

uh

able to distribute to many, many people.

Um, what do you think of that idea?

Is that is that maybe the difference between like someone that's doing agentic
engineering, kind of orchestrating and organizing the entire process with agents where

they're an expert versus like me, who's just like the human in the loop?

Sure.

So first off, vibe coding is extremely useful and the right approach for a variety of
things.

One is like coming up, basically prototyping, right?

Coming up with what you want.

There's no better spec if you're an engineering team to go build something out rigorously,
build something out mature, than to go in and take a um a prototype and say, hey, this is

exactly what I want from a functionality perspective.

And so I think it there's an opening where you don't need to route everything through.

necessarily a product manager that needs to go do all that stuff for you to have some
engineer go prototype it and get really confident.

It's now possible to unlock that far closer to the subject matter expert, the domain
expert associated with it.

So, you know, what's worth your FastSpring I highly encourage you if you want something
and you want to go vibe coded, vibe coded and it's like way better than a spec or an ask

and you have the comfort of having played with it.

Whenever you that's the whole point of prototyping.

And it used to be expensive enough to prototype that you didn't do it except for kind of
like

more important higher leverage kind of activities.

Now it's really cheap.

You can do it for anything, even little internal tools.

And so and so the other one is vibe coding when you go and apply it to internal tooling or
things that you just don't need that maturity rigor.

You don't need things to have four nines of reliability sometimes.

You it's okay if it breaks or if it has bugs, you know, for internal tooling, especially
if you're the, you know, the builder of it.

You've you've hit a bug, you just go ask it to change it.

You hit a

Hit a snag where it's going down all the time, say, Hey, I need the reliability improved.

And you can vibe code your way through, you know, the the egregious ones and you can
accept those kind of faults associated with it.

Typically, too, if it the it doesn't have a like a high scale and you don't have to worry
about the scalability, there's another angle on it that uh you know you can be lax on.

So it's definitely something I feel like everybody, regardless of uh technical capability,
should should put in as a tool in their toolbox.

Yeah, the internal tooling has definitely been an eye-opener, like, we could do this or we
could do that.

And then I like your point on the prototyping.

I have a friend who had a kind of tech, you know, uh SAS idea, technology idea, and she
was asking me about vibe coding and I was like, use it to make a prototype.

And then if you like what you see, well then figure out how you get a developer involved
to help you bring it to that next level.

but that's a really good point about engineers also being able to do that as part of the
process.

To help them get their head around the problems that they're solving for faster.

So, one of the things that's really interesting to me is this idea of agent swarms.

Help me understand what an agent swarm is and why would I even bother with the swarm?

Why not just have one agent that has the various skills I need to use?

Sure.

So a number of things.

For one, it's as if hey, is it better to just have one engineer to work on it or a lot of
engineers to work on it?

Typically, more engineers will work on it, but as we know from the mythical man month, you
know, you can't have ten engineers have a baby in one month.

Um, and so the uh basically uh coming up with a way to at least have some parallelism
there if smartly done is really important.

So that's like

kind of the first and obvious area, but it's maybe not even the most impactful.

One of the things you could do when you have multiple agents is you could basically you
have a generally you have a parent agent, like a master agent like that comes in there and

it knows the initial ask and intent.

And then it goes and breaks down a bunch of subtasks that need to get done in that master
agent.

And then it'll go hand off those subtasks to specific specialty agents, right?

You could have it be a generic agent, but it's better if you have a specialty agent.

What a specialty agent does is it takes

What gets passed to it in all the context that's built up there.

And it adds some additional context that includes how to do that role very specifically.

So you could have a security agent that goes in and anything that gets planned, make sure
it gets planned to be really secure according to these standards and looking out for these

things.

You can build up what you consider that great security agent.

You'd also have a security audit agent that on anything that gets pushed, you know, gets
reviewed accordingly there.

And that has specific instructions on how to.

validate and test those kind of aspects associated with it.

So I in my stack, I have uh I mean I guess it depends on the number of projects, but
generally I have anywhere I I often have at least fifty different subagent definitions,

which really should be thought of as different competencies that exist in there.

And I have a master agent that can go in and funnel to it.

And the reason that's real important is it keeps the context window cleaner.

One of the

The biggest things that really matters or separates out successful and less than
successful agentic engineering, in my opinion, is being really smart about your context

window.

And just to recap for those listeners that may not be asked the question, what's a context
window?

It's basically all the additional content you bring to the table when you go in and talk
to your LLM.

So if you think about it like a Chat GPT experience, which everybody I think at this point
has had, um

You know, it not only has the start and ongoing conversation that gets brought into every
other response that it gives you that you build up over time, but it also has memory where

it goes in and pulls that stuff in it.

When you're talking about like an advanced agentic engineering stack and setup, what
you're doing is you have source code that you're searching and pulling in and bringing

that into the context window.

You have, you know, specs that you're bringing in, you have policies and practices and
domain.

models and all this kind of stuff.

And the really good stacks are really efficient at bringing that in.

And what's nice about subagents and doing swarms is you can isolate which pieces get which
chunks of context, which keeps the context window lower, which means higher quality

results is uh as well too.

So the parallelization and overall higher specialization and quality results are the big
answer or reasons why.

So churning on these jobs in parallel helps you get the overall project done faster, but
also having smaller context windows helps with higher quality products.

So like good guardrails basically to keep it in there.

And hearing you talk about these swarms kind of invokes in me principles around like CI/CD
where you have like a suite of regression tests, where you have lenting, where you have

all these different kind of quality control mechanisms along the way that are kind of all
doing their own job in a automated and standardized way.

It feels like agent swarms are a bit of an extension of that.

Is that a fair observation?

They're a tool, uh they're both tools that essentially play hand in hand associated with
it.

I don't know if I think of it as an extension.

Let me say this.

The when you really want to cruise with agentic engineering and go to the really fast
speeds that are possible, you need to rethink where you validate uh in your overall

agentic development lifecycle.

And so one of the biggest validation

mechanisms that exist in traditional development is basically the PR review, the the pull
request review.

And so you have other engineers go in, actually read the code that gets written and get a
change.

Additionally, even in building, you're going in and reading your code, you're writing your
code in traditional development.

Um, that goes in there.

And so you're building that.

And so very quickly, if you start going fast, you find that's the limiting factor is
actually reading and understanding that code and that kind of stuff with it.

To be able to go get to a higher level

while still keeping enterprise grade uh rigor involved, what you need to do is be able to
have really robust guardrail setup.

And that's where CI/CD comes in.

You know, that's it's more of like that's more of like a tactical tooling kind of solve
for it.

But at a high level, what you need to be able to do is you need to have incredibly good
test coverage.

Um and so I'm talking like, you know, why not have over a hundred percent, which means
like every line of code's checked plus some checked multiple times with different

Flows and scenarios that go there.

So really, really strong test coverage, unit tests, functional tests, integration tests,
data tests, fixtures, et cetera.

fuzzing tests, like literally every kind of testing that exists, you probably want to at
least consider putting in there and have it be super robust.

Another important guardrail is observability.

Going in there and being able to actually see the different actions flowing on your
system, the conversion rates of all the different funnel steps.

You know, golden signals with like error rates, saturation, traffic patterns, et cetera,
with really good alerting setup around it.

So that really good observability and alerting stack becomes way more important.

And then the third piece, which is where product uh management evolves quite a bit in this
new model, as I'm seeing, is the specification, is what at least what I'm calling it right

now.

What we're talking about is extremely articulate uh specification.

Of exactly what the behavior of the system is, both in happy path and edge cases and stuff
that exist, along with like user profiles and all that kind of stuff.

There's a lot of rich data that we create and often have in our heads, but sometimes write
down uh as part of product management during product discovery.

That's gotta get to like a level that's never be s been seen before.

So there's like spec driven developments getting really popular around that kind of stuff,
but it really means just really clear definitions around what's done there.

If you have that trifecta of guardrails.

That's when you start getting comfortable that your validation level is at or better than
it traditionally is.

And you're able to stop having to need to validate it with reading every single line of
code.

You still want understand the architecture, drive the architecture, you still want
understand the the product strategy and the flows and the directions and stuff like that,

but you don't need to literally read every line of code associated with it.

So the guardrails are important, of course.

And you kinda talked about how having ex re super extensive testing coverage is like you
said more important than ever.

It is the and I'm assuming it's easier to get better test coverage as well.

It would insane to invest using traditional approaches to come up with this rigor of test
coverage that exists normally, or at least a lot of companies it would be tough to

swallow.

We kind of be more pragmatic traditionally of you know, you know, forty, sixty, maybe
seventy, eighty percent test coverage, cover the happy paths and some of the the obvious

bad paths, particularly if they introduced issues in production to have them as regression
tests.

But um the uh once

all that kind of stuff is in place, uh that's where you can really start to have
confidence that the system's gonna stay on the rails and and and fulfill what it needs.

So of course we always want like super extensive test coverage, but it sounds like in this
case with agentic engineering, because so much of it is abstracted away, is that one of

the reasons why it's more important than ever?

Is because you're of trusting what it's creating in some regards.

So therefore you want to make sure you have like super hardcore test coverage.

Yeah, enterprise grade agentic development or engineering, I should say.

Um, to use your words, it really requires having as much or even more confidence that the
code behaves exactly how you want to.

And so that's why I think those those three guardrails, it's almost like the uh, you know,
uh the you know, the triangle to success agentic engineering, if you will, but they all fe

like interact with each other in ways.

Really strong specs.

Becomes really easy to turn stuff into really strong test coverage.

Really strong specs, really good to create the observability.

The observability is a real-time ground truth of what's happening at any given moment in
the system, you know, where the test coverage is, you know, making sure that the

fundamental behaviors of the system don't regress or, you know, go astray and what's
what's needed overall with it.

And if you see cases where the observability or the uh test coverage fail, that's where
like the spec needs to be better articulated and tightened.

typically to make sure that that behavior is encompassed within it

So for agent swarms or agentic engineering in general, how does it work across teams?

Like you set up your swarm, but like how do you make that work across a larger organ uh
engineering organization?

For sure.

A lot of engineering organizations that I talk to and see, they kind of like, hey, let's
hook everybody up with Claude Code or similar kind of tool or tools.

And they say you can do your normal job, just use agents in it.

And the reality is to get a high performance stack up, you got to go in and create those
subagent definitions tuned to your stack, tuned to your practices and policies that knows

about all this kind of fundamental knowledge that you have, like that might be in a wiki
or whatever, like your spec type knowledge um associated with it.

It's not all in source code.

And so setting all that up individually by individual individu people on the team or
different teams, they're going to have essentially some um, you know, one, you gotta

repeat that effort off with everybody or at least whatever level they go in and build it,
which is why it's way better to have a deliberate shared way to be able to go in and

empower people to work at these higher levels of agentic engineering, which requires
deliberate planning uh and thought put towards it.

Like one example.

Having a vector store, um, which is like a data store that allows you to look for similar
content based on what you're looking for.

and it'll search large, it could index and search across large uh bodies of of knowledge.

Could be your code base, but most tools do that out of the box.

But you wanna like incorporate in your wiki if it's got all your product documentation uh
and other potential data sources, and it indexes it.

It makes it real easy to find it.

So a really good stack can go pull that into the context window, the right.

data that's needed overall.

Um, and so that's that's what I would say is like the key part of that.

Okay, so that makes sense.

And obviously you don't want a bunch of snowflake configurations out there where people
are like doing their own thing.

Um, so like all this, of course, is happening really, really fast.

And I feel like even within the last year, we've kind of gone from like people maybe even
being a little embarrassed they're using agentic development to like now it's just a

requirement and like if people are getting left behind if they're not adopting it.

But to kind of get it more to like the human level here.

Um, how do you what what are like key things to pay attention to to get your team to adopt
engineering, agentic engineering in a in a way that allows them to do their their best

work in a healthy way?

Like how do you address the human side of adoption with your engineering team?

For sure.

So um There's a bunch of things I think that are that I've learned or uh validated or even
some have invalidated.

But one is you have to still keep the responsibility with the human being that the code
being pushed out as to the standards that the company expects.

Claude ate my homework is not a valid excuse, right?

Like at the end of the day, I don't care if Claude wrote your code that you have to be in
there.

And that in turn is a forcing function, right?

Because

You know, it takes time for people to learn the tools and the new workflows.

And so if they're responsible, if a bug goes into production, if you know something were
to bad to happen, like they've over the years, traditional development, we've we're used

to this.

The PR review, you have the initial author and the PR reviewer kind of have a degree of
responsibility over what goes into production.

And so until a team member has enough confidence with the tools and what they could do and
that they have they shift their normal verification validation, you know, anchor.

that they have into a higher level, they're not going to be able to go in there and um,
you know, be able to have confidence with it.

That I think's one of the longer tail things is people kind of go in their agentic
engineering journey that you can't rush that fast.

There's no just trust me or just go with it type of thing with it.

You know, you need them to understand what's happening, what the tools can do, and to have
enough confidence in that uh security layer that exists overall in it.

There's a lot of reactions people have when they get into this.

particularly if they maybe did stuff early and kind of said, it's not ready for prime time
or whatnot, and then woke up, say, after November when the newer anthropic models that

were particularly a leap in my mind in terms of efficacy.

That's where you started to see really good engineers go, wow.

Right.

Like I had I had one engineer once say to me, like,

Man, I'm glad I'm towards the end of my career.

I don't know how much is gonna last.

So sometimes you go into like the doomer kind of mindset.

I don't actually subscribe to that.

Everybody's gonna be a force multiplier, uh, that or have a force multiplier that they
didn't before.

And I think it's gonna be measured in hundreds of percent or X factors.

It's not just like 20, 40% improvements that companies just dabbling in and see right now.

And when you have that higher level uh impact that you could do with it.

Yeah, like we're not a cost center generally in software.

We're often a value creator.

And I've never been somewhere where we didn't want to build way more than we could.

Even when I was pretty well at companies that had a lot of funding.

So I'm I'm a believe believer that uh I always pronounce this one wrong too.

Devon's paradox Devon's paradox or j j Jevon's paradox.

What those?

Anyways.

Yeah.

So it it's where basically the

cheaper something gets, the more demand there becomes for it.

Right.

And so you might have back in the day when electricity came into the scene going, I got
enough for my six light bulbs in my house.

This is going to be the end.

The market, it's going to be hyped, you know, we don't need more electricity.

But quickly people found more uses as electricity got cheaper for, hey, you know, I got a
dishwasher now.

Woohoo.

So um, you know, there's all this uh, you know, buildup associated with it.

I suspect software engineering is going to be largely like that.

Unless it's actually an organization that does treat software or their software stack as a
cost center.

Like if there's just a fixed stuff set of stuff they gotta do, sure, maybe they don't need
to do way more stuff.

But even then I would challenge them to rethink from first principles of what's possible
with going way faster and way cheaper.

So making them making sure they understand they're responsible for the output.

So no Claude ate my homework, reinforcing the need for the expert in the loop.

We we we need your expertise to make this good.

And then it's interesting, and I I guess like a a D V is a maybe it's the D V paradox, is
there's I what I always say is there's more ideas than time.

Yes.

So as we become more efficient, all those ideas that are filling up everybody's backlogs
and and the even bigger ideas that we don't have time for, we're now gonna have more time

to be able to address those things.

And so maybe we run out of ideas at some point, but uh at least we're we're we we don't
see line of sight to that probably today.

Um, even in the efficiencies we're seeing, and at least for a good long time, we're gonna
need that expert in the loop.

So like

some non technical exec like myself can't roll in and like make the next production
feature for our platform.

that that's not gonna happen.

We're we're always gonna need that engineering expert in the loop.

Prototype the next killer idea, by the way.

Sure, sure, sure.

Yeah, but not ship it to production, right?

Yeah.

That's cool.

Um, so we're where so we talk about the future a little bit here, but where do you think
all this is going?

Like obviously we're abstracting out a lot of like the kind of grind work in in the
engineering world.

What where do you think this is all going?

I think you're gonna start to see You're starting to see it in the very earliest of
companies, but as companies journey and get to the spot where they can create product

value per headcount at like a five X, 10X really big factor, we're gonna start to see
certain companies take off.

We're gonna start to see I mean it's gonna be great for uh user experiences, right?

Like they like they're gonna get way more functionality, things are gonna get far more
robust.

far more healthier, right?

That's the whole cost of it going down associated with it.

And ideas that didn't make any sense before because of their effort that would be taken
and the risks associated with it.

You gotta keep going back to first principles.

But there's gonna be the surge of value creation that's going to happen across the space.

Some companies are going to be quicker to adopt it, some are going to be slower.

The ones that are going to be quick are probably going to eat the slower companies lunch.

And there'd be new companies that come out of the uh the the wildfire ashes, so to speak,
that are going to emerge that that

wouldn't make sense before were the same companies that previously went into the startup
graveyard because of the costs or complexities of trying out those concepts.

Those are all now gonna be viable and on the table.

And some stuff we've never even thought of.

Unlocking big ideas.

I like that that view of the future.

Um, so uh that's that's fair advice or fair observation.

All right.

Well, we covered a bunch of topics here today.

So my last question would be if people only remembered one thing you said today, what do
you think that should be?

I think that

Going on and thinking of your agentic journey that your product engineering team or
company might undertake to be able to unlock those value levers, it is focus on the actual

value that you could realize on it and understanding it's a journey and that it can't be
done overnight.

Like even if you know all the things and know how to go in and operate at a very high
level of agentic maturity, it takes time to get a whole team of humans to come along with

you and to learn those skills, get comfortable enough, learn the strengths and weaknesses
of these new tools.

and get adjusted to them to be able to go in and start introducing the value.

So treat it as a journey with various stops along the way with various goals in the way.

I like that observation.

Treat it as a journey.

And I love how you also focused that last point on the people element of it and kind of
bringing all that together to help drive value.

Well, this was awesome.

Thanks so much for joining us today, Chris.

Well, thanks for having me on.

Always fun to talk with you.

Absolutely.

If you'd like to learn more about Chris's up to, you can check out fastspring.com.

Thanks everyone for joining Growth Stage.

Again, I'm your host, David Vogelpohl.

I support the digital product community as part of my role here at FastSpring.

And I love to bring the best of the community to you here on Growth Stage.

Bye, everybody.

Take care.