Subscribe
Share
Share
Embed
The Product Engineering Podcast explores how software teams can move beyond shipping features and start delivering measurable outcomes. Hosted by engineering leader James Charlesworth, each episode covers practical ideas for product engineering, engineering leadership, team operating models and building products that create real impact.
It's not necessarily like how fast you
can use AI to build something, but it's
still the blockers around decision making
or waiting for somebody else
or waiting for another team.
Hey, welcome back to the product
engineering podcast.
Now this week we're talking about how
product engineering actually functions in
a modern product led organization.
And there is nobody better to talk to us
about this than Anna Dick.
Anna is the CTPO at Capsule, the CRM, and
she has over 20 years experience in the
world of product leadership.
So Anna, welcome to the podcast.
Thank you.
Thanks for having me.
So one of the things we talk about a lot
on this podcast is that shift between
engineering teams essentially delivering
a roadmap and building to respect towards
taking much more
ownership over product outcomes.
So I wonder what's your experience in how
that's shifted and how do
you do things there at Capsule?
Yeah, so Capsule, we are a company of
around 50, so we're not massive.
We are remote, but we do have a bit of an
office in Manchester as well.
I think when I first started at Capsule,
there was already a bit of a product
mindset within the team, but we were
still quite siloed in
terms of our approaches.
So the kind of business side of things
and then an engineering function, there
wasn't a lot of product
or product kind of mindset.
So over the last couple of years now,
we've been working on how we get that
more into the business, but then also
into the teams in terms of
that shared responsibility.
I think originally there was a lot of the
engineering team spending time kind of
building the things and not necessarily
understanding the customer, the outcome
and kind of where we wanted to get to.
And that wasn't due to like
a lack of appetite for it.
It's just the way that
it would be structured.
And I think that getting that product
mindset into the teams was something that
was quite intentional for us.
So we did get some external help.
I think when I started at Capsule, I
don't know if you ever had the kind of
moments where you feel like you're the
only one talking a language or speaking
about a certain thing.
So it's quite hard as one person in an
organisation to kind of
invoke that kind of change.
So we did work with the consultancy in
the early days to actually do upskill and
learning sessions
that were for everybody.
So that was all the engineers very
focused on kind of the execution and
understanding around outcomes, but also
sessions with our exec as well, because I
think it needed to come from both sides
in terms of how we work.
It was also about how we kind of
organised, how we got some product
management experience into those teams,
as well as the engineers thinking about
those outcomes as well.
That's really interesting because I think
a lot of engineers want
to do a lot more of this.
They want to get involved in discovery or
they want to speak to customers, maybe
less of the supporting after it's
released, but they should be doing that.
But often it is just it's both the given
the permission to do it and given the
authorities to it, but
then also given the education.
What kinds of things did you find most
valuable from people that came in and
talked to them about it?
So we had quite a structure.
I think initially we
did like a bit of it.
I think it was maybe eight weeks where we
covered different themes.
So it's what is an outcome
over just kind of output.
For example, we looked at different kinds
of way to structure the
teams around discovery pieces.
So the importance of research, having
people involved in calls, research calls
and how that kind of fed back.
We were kind of quite focused on kind of
user stories and story
mapping, I think at the time.
I think we've probably
even evolved since then.
But I think just helping people put their
the perspective of the user in terms of
what that outcome is rather than do this
task, build this thing.
It's like what's that overall piece that
we're trying to achieve as well.
How big are your engineering teams or
product engineering teams?
So we have four kind of delivery teams
and we are very much cross-functional and
that's something that during
that period kind of improved.
Although the kind of being
cross-functional in terms of those
engineers and maybe support and CS team
didn't necessarily include marketing or
more products, you know, that kind of
full intent cross-section, like a unit of
delivery who could kind of take an
outcome and run with it.
So the reason I ask is because everything
you're describing of getting everybody on
the team more focused on the outcome and
speaking to customers can run a risk of
having that too many cooks in the kitchen
kind of thing where a customer is sort of
dealing with an entire
team instead of an individual.
So how do you get around that of giving
everybody the ability to contact
customers and do some discovery but
without having the entire team trying to
pile onto one problem?
Yeah, so I think, you know, we've been,
you know, changing our team
structure even more as we go.
We are now bringing up kind of a pair of
developers very much upfront working with
product in this discovery phase as well.
And each of those kind of pairs will have
a different problem or outcome that
they're looking to solve.
So, you know, is it helping our customers
get more leads or is it helping them on
board those kind of outcomes?
So that quite small team is then involved
in doing the research, understanding what
the customer needs, doing customer calls,
but also building out the
prototype as we go as well.
I think because we do want to have more
engagement with customers, obviously it
can be challenging to get time with our
customers and often the people that want
to speak to us are, you know, the early
adopters, they're the people that, you
know, don't necessarily are not
necessarily as objective
with feedback sometimes.
So we have started more of a kind of
continuous discovery element where we are
looking for other types of users.
And we do like provide a little bit of
incentive to help get, you know, not just
the people that would want to speak to us
normally as well
involved in that process.
That's something that a lot of engineers
who first go into like product
engineering don't really understand is
that not every
customer has created equal.
If you only design for the people that
are willing to speak to you, as I'm sure
you know, but a lot of engineers, like
because a lot of their experience of
customers is either when something goes
wrong or they just see kind of
generalised customer feedback across the
entire thing, it's difficult to
understand that like you're right, a
customer that's more likely to be an
early adopter and jump on and do some
discovery with you doesn't necessarily,
it's not representative of
the entire customer base.
Yeah, exactly.
And what do you look for if you're maybe
hiring or putting somebody else into a
new role inside your organisation?
What kinds of skills do you look for that
you can develop for effective people in
product engineering, both on product and
the engineering side as well?
Yeah, so I think it's curious, curiosity,
I guess, in terms of definitely that kind
of learning mindset in terms of just
being interested in
understanding all of those wider roles.
So, you know, not just, you know, how you
might build something, but a real
interest in like, why
are you building it?
Who's it?
Who's it for?
What are they doing?
So I think that's one of the things we're
looking for our teams to be more
conscious of is what is it actually, you
know, once it's going through the beta
phases, is what's that feedback?
What are the numbers?
What are the insights?
That's kind of saying, yeah, do more of
this or actually, you know, don't be
afraid to go, that's not
really the right thing anymore.
And like actually using some of that data
to kind of pivot and
change paths as well.
So yeah, definitely curiosity, I think
more and more the ability to
work wider across the stack.
So, you know, whether that's product, who
can build prototypes, designers who can
build, you know, engineers who are happy
to get on interviews.
I think what we're seeing is that kind of
widening of the scope
of all of those roles.
It's kind of getting the, you know,
groups of those people together to be
able to be that kind of unit of delivery
that can solve those
customer outcomes together.
Yeah.
And if you do have a wider role, and this
is something that a lot of people are
saying is that, you know, for example, AI
makes it so that a product manager or
designer can build a prototype.
Getting closer to customers makes it so
that engineers can be a
bit more outcome driven.
But how do you avoid kind of peanut
buttering everybody's role?
So how do you make sure that people can
still bring their specialist skills?
So if you have somebody that's really,
really good at kind of back end
architecture, how do you make sure those
skills are still used
effectively in that context is shared?
Yeah.
I mean, I think the way that we're
saying, you know, we'll
always need the experts.
And I think we're very clear on that.
And you know, not every engineer is
comfortable being on interviews.
And I think there's different ways to
kind of spread across the stack.
And I think that's around how we kind of
form or create the teams so that you do
make sure that you've got the specialisms
within each area for the teams.
But they're also kind of happy to be
like, as a team, what do we need to do to
get this, you know, product to the next
step in front of customers as well?
And I think it's a bit of a training and
exposure as well in terms of the areas
that people feel comfortable with.
And, you know, we now have some of our
front engineers who are using AI to mock
out some of the back end as they go.
So it kind of, what can we
use AI to help unblock people?
That doesn't necessarily mean that that
back end would ever go into production as
something that we would
maintain as production code.
Because there's that gap between like,
what is the prototype, is something
that's secure, maintainable, and
manageable on an existing stack.
You know, there's a lot to do there.
But it definitely helps teams like
unblock themselves in terms of not
waiting for those kind of specialists to
be able to get that next version that we
can maybe prototype or run some data
through or get in front of customers.
I also wanted to ask about process.
So you've been doing this
game for a very long time, right?
Like you would have remembered when Agile
came out and then everybody had to kind
of over index on all of these Agile
ceremonies and other ways of working.
In terms of actual processes, like
day-to-day ceremonies and things like
that, have you noticed a shift there?
Is there anything that you do now that
maybe we wouldn't
have done five years ago?
So, you know, we've
been kind of loosely Agile.
I think we are Agile in terms of we pivot
and we move quite a lot.
We do an element of quarterly planning in
terms of the outcomes and the objectives
and the customer goals we want to get to.
And then we might have, you know, certain
things that we want to experiment or a
bit more mature thinking around the
things that we want
to build with NetBora.
And we do prioritise them based on, you
know, indicators that we're seeing,
whether that's from our customers or
certain data points.
We still very much do
that discovery phase.
But I think now that we're using AI and
we're bringing the engineers forward to
support prototyping, that discovery used
to be kind of done more in isolation with
the product and designer potentially.
So we're probably spending a bit more
time on the thinking and investing more
people in that process
with a bit more rounded view.
So I think in terms of ceremonies, we
still have our kind of two-weekly cycle,
but that planning is much
lighter on a weekly basis.
We tend to do a lot of the planning kind
of upfront in our discovery phase.
I think the prototype effectively becomes
the thing that we want to build.
And then once that's validated with
customers, it's how do we break that down
to build it over a number of iterations?
We don't like, we're not very deep on
like counting points or, you know, kind
of scrum type things.
We have very much of a constant flow,
although we do have this kind of two-week
checkpoint where we do say, what do we
want to achieve in the
next two weeks for each team?
So that they're very aligned.
And then we can line up other areas of
the business as well for that too.
Yeah, I've noticed a
death in story points.
I think the reason we don't count story
points anymore is because that used to be
the riskiest, most intensive part of the
investment was turning
a story into some code.
And so you really needed to be able to
accurately predict that.
But now if you can turn a story into some
code quite quickly, it
doesn't really matter.
If you use those AI coding tools where
they turn around and say, oh, this will
be about a week's worth of work.
And you say to the AI, like you're an AI,
you can do that in 10 minutes.
Stop doing it.
It's a week's worth of work.
A week's worth of work five years ago is
not the same as a
week's worth of work now.
Now you can go from an idea to a
prototype extremely quickly.
But yeah, I do think sometimes people
over still over-index
on prototypes, though.
So you mentioned that you would do a
prototype as part of the discovery phase.
There is both that sunk cost fallacy of
thinking, well, we've
already built a prototype.
We should continue in this direction.
And then there's also sometimes the
perception that the prototype is ready
and it's scalable and secure and stuff
like that, which it isn't.
So how do you get
around that mindset shift?
And that might often be a case in
leadership more than it is on the actual
teams, where you will look at a really
great looking prototype without really
internalizing that
there's a bit more work to do.
Yeah, definitely.
And I think that that expectation
management is key because I think as soon
as certain members of the business see
something that's working, they're like,
oh, that's that's it.
That's then ship it.
You know, that's a common kind of jokey
phrase, like not kind of joking.
So I think that's a lot of work we've
done across the business to help people
understand the difference between that
prototype and a production version.
But I think because we've got the
engineers working more
upfront on the prototype.
Product person might start to like
visualize an idea
themselves in a prototype.
But when we get the engineers involved,
they're actually building the prototypes
into our code base, you know, so they're
using a lot of like existing components,
potentially existing API endpoints.
So that gap between what a prototype is
and what that production version as they
feed back over time, I think that's going
to is going to reduce in terms of the
effort between prototype
and what live build is.
But that doesn't mean
it's the right thing.
So it's still making sure that we're
going through enough of
that validation phase.
So just because we've built it doesn't
mean we should ship it.
Yeah, I'm always quite sympathetic of
like cyber reliability teams and security
teams because their work is so hidden and
their work is the difference between
something being mocked together and tried
out the few users and
actually scaled out to production.
And I think a lot of people in security
and cyber liability are finding that
their workload is just going up so much
because it's so easy to make stuff that
needs a security review or it needs
testing and things like that.
Like do you bring people from the kind of
technical support, security, all those
kinds of things, do you bring them into
the process at any
point or how does that work?
Yeah, they're in the
process from the beginning.
So we tend to kind of kick things off
with kind of product,
kind of canvas, I guess.
So it's like why we want to approach this
problem, what are the insights, what are
our customers kind of
saying, which is quite light.
And then we kick that off with the whole
of our delivery team as a like, this is
the problem space we're
going to start looking at.
And that has CS support, marketing, sales
where we can get them, but we've got a
very small sales team.
But just to try and get that
understanding quite early and then say,
who does need to be involved in this?
But then it tends to break down to a
slightly smaller team, product
engineering, design,
who would maybe go off and do some of
that discovery work, but they'd link in
with the experts in their team as and
when we want to explore.
But when we get to the point of full
build, then everybody comes back together
and is more involved.
Yeah, one thing I did on a slight
tangent, one thing I
really wanted to ask you.
So you've been doing product leadership
for a very, very long time.
A lot of people that listen to this
podcast are from an
engineering background.
Maybe they're a senior or a staff level
software engineer, and they're having
this sort of identity crisis because
their entire life has been
built around writing code.
And now they're realizing that, okay,
that is now a case of
directing agents to do it.
So a lot of people are thinking, okay, I
know I need to become more product led.
I know I need to speak to customers.
I need to care about outcomes.
What advice would you give to people that
have been software engineers for several
years and they want to become more
product led and they don't quite know
which direction or
what skills to pick up?
Yeah, so I think getting involved with
the product teams or even like the
business side of things.
So if you're already working in a
cross-functional team, is trying to
understand all the
different roles within there.
I think a lot of the product mindset type
piece is like really understanding what
ultimately you're trying to achieve.
What's the behaviors that
you're trying to change?
So actually spending some time with
customers, maybe understanding some of
the persona data that your teams have
around the customer base.
Spend time with maybe your customer teams
or your sales teams as well to try and
understand like how do people use our
products or services.
I think that's really helpful as well.
Yeah, no, it is.
I completely agree.
I know some CPTOs and product engineering
leaders that will, for the first two or
three weeks when a new engineer joins a
company, they'll embed them into the
marketing team or they'll embed them into
the sales team or something.
So they actually get a feel for how
things are sold because for so long
software engineering has stopped at the
Jira ticket ending on done and the code
being merged and then they
move on to something else.
And so for a lot of software engineers,
like the world outside that Kanban board
has been quite limited.
And so, yeah, it's an
exciting thing to pick up.
And I think this kind of getting the
engineers involved in the
discovery work up front,
we've had some great feedback in terms of
that approach and how that's kind of
gone, "Oh, I didn't know that, I didn't
really think like that in terms of how
people might use the products."
And you're right, rather than just seeing
a list of tickets to work from, being
kind of responsible and having a bit more
of autonomy as well around the decision
making that's involved
in creating these things.
Rather than working off a ticket backlog,
I think people feel a bit
more empowered in that sense.
Yeah, I remember the first time I looked
at a session replay to
always in money supermarket.
And when you see somebody moving their
mouse around the page and not opening a
accordion, you're thinking the
information is right there.
You just click that
button and it opens up.
Why haven't you clicked it?
And then to really get your
top into the heads of that.
I saw a really good talk of somebody that
works on the Gov UK website, which is
genuinely a landmark
piece of UX engineering.
Where they did a lot of research of
people that were not
like digital natives.
And so they were trying to use the
government website and they were
struggling with
dropdowns and things like that.
And those are the kinds of things that if
you've grown up around software and
you've been a software engineer or
product manager, it's really difficult to
understand that other people have
different experiences and they use
products in different ways until you
actually see it happening.
So for me personally,
that was my opening thing.
It was really good.
Yeah, and I think the session replays,
but then also just the data, from tools
like Pendo, we can now use the MCP server
to actually get some of that data kind of
straight back into Slack channels.
So it's instantly starting to see how
people interacting with it or maybe not
interacting with it.
And what does that mean?
I think the whole team can then
experience that data, can talk around
that data and just is living it a little
bit more rather than, oh, we've built it,
I'll hand it off and we're
moving on to the next thing.
How do you encourage engineers?
Because a lot of engineers will see data
like you might find in Pendo or
competitors to Pendo.
They might see that as not their domain.
So they might think, well, my data is the
memory usage on the
database and things like that.
Right?
So how do you encourage people from an
engineering background to actually engage
with product analytics data?
So I think it's making it accessible.
So I think like we would have had very,
very few engineers who would have logged
into Pendo, for example,
to like look at that data.
Our product managers might have presented
some of that data, but actually when
we're presenting it more in line with
this is just released, this is the next
day, oh, we've got five
people have started using that.
They were actually finding like an energy
about it because no one wants to build
something that's not used, you know, or
isn't working quite right.
So if there's that data to actually say,
how could we make this even better?
Then I think that's really powerful.
But yeah, making it kind of really
accessible and putting it where our
engineers are so that they
can, you know, they can see it.
Okay, the last question I have for you.
What do you think the future is for the
product management role and for the
software engineering role?
Do you think there will remain separate
roles or will everybody
just be a product engineer?
Like I said, I think there
will always be specialisms.
You know, maybe it's different in a
startup kind of world.
I think for us where we have quite a
mature stack, you know, 15 years old,
the specialists are really important and
I think we don't want to lose that.
I don't think necessarily everybody will
be a product engineer, but I think there
will be, I don't know if I like the word
builder, but you know, that kind of like
spreading across so that you can take an
outcome and you can with the support of
AI, supporting you what the area that
isn't your specialist, you can get things
to a certain point, you can unblock
yourself to get
things to beta or further.
Because I think one of the things I
found, it's not necessarily like how fast
you can use AI to build something, but
it's still the blockers around decision
making or waiting for somebody else or
waiting for another team.
So I think trying to unblock those other
areas so that people can more completely
create, you know, the thing or the
outcomes that might not be the final
version, you know, that would be reviewed
by the specialist or inputted or maybe
replaced at some point.
But yeah, I think having these more unit,
small unit of delivery teams where you've
got a mixture of capabilities, maybe with
specialists kind of sitting around those
teams that would still care about the
architecture, you know, the data
architecture, the security,
maintainability, all of those things.
Because I think those are all things that
you really need to care about.
Yeah.
But without having, you know, so I think
still having a
specialist, but being more builders.
Yeah, it probably is an organization size
thing because small startups have never
really had a split between product
management and engineering.
Like if you're in a four or five person
startup, everybody is getting hands on
and everybody is talking to customers and
everybody is, if they can, writing code.
So yeah.
But maybe that's what, that's probably
part of what helps them move fast.
It's when you try and scale that and
you're adding more people into the, you
know, into the mix in terms of how that
can start to slow things down, I think.
All right.
Well, thank you Anna so much
for coming onto the podcast.
If people want to contact you, where's
the best place to find you?
Probably on LinkedIn. I
think that's fine.
Yeah.
Reach out.
Brilliant.
All right.
Well, thank you so much
and join us next week.
And thank you again,
Anna Dick from Capture CLM.