S1E7: The Triad of Design, Engineering, and Product with Johannes Marbach and Callum Upfield

Whenever engineers have something ready, they're kind of usable, ready to be looked at, that's
when I think they should stick up a flag and designers should check out their stuff, do
some testing, and then there should be some kind of feedback loop between the two to get
to the best result in the end.
I agree, and I've experienced that working with you the last year.
It was a really good working style when, as a designer, engineers are sharing progress
because there might be things that have been implemented that differ from the design, which
the engineer might not think much of.
Hi, I'm Karl.
And I'm Danielle.
And this is Productly Speaking.
We're product managers by trade, and here we explore the world of product management.
It's people and their stories.
We promise to keep it entertaining, and maybe you'll learn something.
Shall we give this a go?
Let's do it.
Today we're discussing how design, engineering, and product all work together to best solve
customer problems.
Solving customer problems through product thinking while effective is often very messy.
Often as a product manager, you hear a lot of voices sharing their opinion at once, all
with different backgrounds and experiences.
Each of our guests today has deep experience in their field and occupies a role that needs
to be in lockstep with you as a product manager.
Both Danielle and I have had the pleasure of working with and learning from these folks,
and we can't wait to get into this discussion.
So with all that, who are we chatting to today?
In no particular order, we have engineering manager Johannes and product designer Callum.
Johannes Marbach is an engineering manager based in Germany with over 10 years in the
field.
He's passionate about people and processes that work.
We've seen firsthand the impact his style has on team morale and velocity and how that
can positively drive good product to customers and users.
Over the course of his experience so far, Johannes has worked on all platforms as both
and has grown apps from first use to providing high quality apps to millions of users globally.
Callum Upfield is a designer based in the UK with a specialism in product design and
user experience, and his visual design skills are also incredible.
He really is the whole design package.
Most recently, Callum has been working on a zero to one product for mobile, though his
work history has given him great experience with a range of platforms, product problems
and product teams of all shapes and sizes.
We're pleased to welcome to productly speaking Johannes and Callum.
Thank you.
Thanks for having me on.
So I guess to get us started, what are some of the key values that you guys feel that
you get from working with product managers?
I'd say for me, one of the key values is what I'd call the why.
Maybe it comes with the quote unquote age, but I feel like technology alone is not enough
to motivate me anymore.
You know, I want to know why something is important, what the expected impact is, why
we're spending our time on it really, what all the blood, sweat and tears will be for
in the end.
When that purpose and mission are crystal clear as an engineering manager, that really
also helps me to align the team behind the idea.
What do you think, Callum?
What Johannes said, additionally, being that expert in the particular product area, there
might be more context the product manager has based on whether there's been more conversations
or data gathering.
Like some product managers are quite data savvy, which can be really useful.
Some are very keen to talk to customers and do that regularly.
So I think it's just bringing all that expertise into the process, which helps make my job
a bit easier and helping, as Johannes said, answer those why questions.
Johannes, you and I have spent a lot of time talking about the value of feedback and giving
each other feedback along the way.
I think we naturally jumped into that.
Callum, what's your experience of feedback with product managers so far?
I think it's pretty mixed.
I think generally it's always useful to get feedback from anyone.
It's just another data point and something to use to maybe adjust designs or just keep
in mind for the future.
I think feedback's always best received towards the beginning of a project for a product manager.
I've had a few times where feedback, my very key feedback, is received at a handoff stage,
which obviously is not as useful as it could be if it was towards the start.
So feedback's great, always love hearing it, but there's definitely a time where it's best
received.
Yeah, I can see a situation where the reason that that feedback is received at a handoff
stage as opposed to at the beginning is because the product manager happened to receive some
new feedback that they didn't have before.
And all of a sudden it's like, well, that changes everything, like a customer or a prospect
or some marketing data that says, really, if you go in the direction you're currently
going in, you're only going to end up exactly like your competitors and there's not going
to be a differentiating factor.
However, if you went this other way, that would differentiate you, it'd be valuable.
And so now you've got this product manager coming at you going, oh, you know how we said
we wanted to do it like that?
Do we really need to now do it this other way?
Yeah, I don't think that's a massive problem if there's time to change it.
The issue arises when there's not.
And obviously that depends on company size and resources available.
And yeah, things crop up all the time, of course.
You can't predict a client request that comes at a late date that is key to a design, but
how to deal with that when it needs to be released the next week, that's the key question,
I think, sometimes.
Or somebody on the management team getting some new bright idea that now that's the direction
that they've got to see it go.
And so it just kind of comes from on high and it gets passed down and we just have to
kind of absorb that because a lot of the times in those scenarios, there's no pushing back
on that.
I think that's why that that why piece that Johannes, you were talking about is critical
as well, because when those late pieces of feedback come in, if you can all still be
aligned on the why and challenge it, then it's really helpful.
So what do you guys wish product managers knew about your role that would make it easier
to work with product managers?
Yeah, direct feedback.
What do you think of me?
So I think a key thing from the design thinking perspective, creating a design can be really
fast by creating a really good design that solves the problems that you have in front
of you.
And that like, suit the needs of everybody involved takes a lot of time sometimes, I
think, because it's quite tangible design.
It's like a visual thing, I guess, that's handed off in the end, everybody can see it.
Everybody can sort of maybe understand it in their own way, unlike code, I guess, which
is harder to to look at from everyone's perspective.
And sometimes I think there's this thought that, oh, design, it's very fast.
So yeah, just being aware that things can take time and what might seem like a quick
change may not be.
I'm always wary when designs come too fast.
Like if we have a conversation in the morning about requirements, user flow, that sort of
stuff, and the designs are ready by mid afternoon, alarm bells are going because there's no way
that we've really accurately thought about all of the unhappy paths and the different
models that customers can get themselves into.
It depends on the way of working, really, because if you are looking for something like
a quick visual idea, that can be done in a very short time.
But yeah, if you're looking for a final, really well thought out design, then that wouldn't
work.
What do you think, Johannes, what are engineering managers need product managers to know?
Engineering manager is not a terribly well defined role across the industry.
It differs a lot company by company.
In most cases, though, a significant part of it is people management, actually.
People management doesn't mean assigning tickets or telling people what to do.
It means creating an environment for people and teams to do their best, coaching them,
helping them grow.
So I feel like the best product managers I've worked with were the ones that had an appreciation
for the fact that my job is about a lot more than just technology.
Some of them even have been interested in brainstorming on people management or team
dynamic topics within the teams we worked on.
So how did those interactions go?
I'd like to hear more about that.
Talking about our observations, me running ideas for how to address certain issues I've
observed within the team by my product manager, Pierre, and they giving me feedback on it.
So I'd say almost at the level that I'm interacting with an engineering manager, Pierre, really,
because they're also involved in the team leadership aspect of it.
I think for me, the triad is so important when kind of running a product project.
So having a product manager, the engineering manager, and your product designer, you should
always be in so lockstep that any meeting could have just one of you and you trust that
one person to represent the three kind of columns altogether.
And being able to build up that level of trust sometimes takes a lot of effort, but a lot
of those check-ins where you say like, okay, delivery, who's responsible for delivery in
this organization?
Is it the product manager or is it the engineering manager?
Because to your point, it's slightly different everywhere you go.
And there's so much blend between all of the different roles.
I guess there's less blend between design and engineering, but product could define
the flows and the designers just put the visuals on top and product could also define the delivery
and engineering managers just put humans next to that.
But I think that's such a black and white way of looking at it and not every organization
is the same.
You need to figure out with the humans that you're working with what works for the three
of you.
The point about speaking with one voice is really important because each of the persons
in the triad will have their own manager and they're going to talk to each other and discuss
and they're going to talk to you.
And so it feels really important that you're speaking with the same voice, even if not
everyone is around.
What do you think the best way to that one voice is?
Yeah, I feel like it's really important to maintain context of what the other people
are working on so that if they're not there, you're at least covering to some extent for
them.
The boundary between these roles should definitely be fluent in some way that it's going to
be good to tap into the other side and understand a little bit about what's happening in your
peers area so that you are able to also speak for them if they're not around or also you're
able to support each other in discussions when you're talking to another group like
your managers.
Callum, how do you feel about the one voice approach?
Do you think it's possible to have an engineering manager defend designs or would you always
want to be in the room too?
I think it's possible.
I think I would like to be in the room most of the time, but it depends on the project,
doesn't it?
If there's a small addition within a settings menu, for example, where everything's been
laid out by the designer beforehand, there's components in place, there's a design system,
a engineering manager or engineers in fact could just probably make a decision of how
to add something if it's small.
But I do think it's always good to have a designer's perspective on something because
there might be some more context, some more understanding that the engineering manager
might not understand.
I think a lot of the designer's work is invisible sometimes, there's a lot of thinking that
maybe is not communicated across like it should do, perhaps, depending on documentation,
depending on meetings that have been previous.
I think I'd prefer to be there for those decisions, it does depend.
Yeah, I think what I was thinking of was more just relaying the bigger idea behind designs,
not necessarily details, because obviously as a designer, you're going to be the one
most well equipped to talk to them, but just maybe high level design decisions, being able
to explain them to other people.
Okay, yeah, then I totally misinterpreted your question 100%.
I totally think that should be the case.
And I've had examples the past two years really working where that's been the case,
like I've been away or designers on certain teams have been away, yet their team continues
because there have been those conversations of a shared understanding of where the project
should go.
So they can jump in and give their opinion.
And I feel like the flip side of the one voice thing is that among the triad, you don't need
to talk with one voice, there should be a lot of disagreement internally and discussion
in a healthy way.
But just externally, I feel like it's important to not let that bleed out.
What would you consider to be internal versus external?
When engineers on the team, for instance, are involved, I would probably still consider
that internal because it seems important for them to understand that there is discussion
and debate also among the leadership of a team.
But when you're talking to senior management, for instance, that feels like a prime area
where you want to talk with one voice to not create more confusion than necessary.
For me as well, it always comes back to what's the psychologically safe environment you're
trying to create.
Johannes, you talked about how the engineering manager role is about creating an environment
and making sure that people are heard and listened to and supported.
And that is so much of the role that you take on as engineering manager.
I think product managers and designers play into that because they're seen as the leads
of particular projects or teams or products.
And you have to be able to have those discussions and you have to be able to disagree with each
other in a safe way and then show that to the team so that environment and that kind
of collaborative space is there and able to be used to its best advantage.
When you're then kind of taking your decisions on a road show to everybody else to say we
made this decision and we think it's the right one, that's where you don't want to show
the cracks because you need people to come along and have confidence in you as a team
so that they can get behind the thing that you're trying to drive.
100%.
I am really fascinated to talk to the three of you about PRDs because I think documentation
is so key in some of this stuff.
Personally, PRDs, I'm not a big fan, but I know that each of us have a very different
experience with PRDs and different thoughts on them.
Kyle's just got the biggest grin.
I agree with you on this.
I've never liked the idea of a product requirements document.
I think it really boxes you in.
Depending on what you're doing, you might want to be boxed in, you might want to have
some constraint.
I mean, if you're working on that first minimally viable product, you don't want that to just
go on forever and never get to a point of done.
Perfect is the enemy of good and all of that.
You can really get yourself in a scenario where you're just never finished.
You do have to draw lines, you do have to draw a structure, and a PRD is really good
at that.
But I think that a PRD is so stuck at a point in time that it becomes difficult to keep
up with any changes that may actually impact the product.
If you do have a PRD that's constantly updated, well, now your product manager's having to
do a lot of work to keep this documentation updated.
Whereas if you have kind of a more dynamic product plan and a tool that can be updated
and used to present similar stuff to a PRD, then you're in a little bit more agile of
a situation.
And I really think that it kind of comes down to PRD maps to waterfall a little bit better.
And when you're doing agile, you've just got to have a little bit more agility, no pun
intended there, to be able to really move forward.
So for me, the PRD is not something I ever want to have to write.
If I had to, I would, but I'd much rather work in these are the features that we're
currently working on to solve this problem in the market.
And when we've marked delivery of these features, we're ready to go.
The one situation where I actually found them helpful was when I was working in a professional
services team.
And so we were explicitly not doing agile software development.
We had a contract with customers, they bought certain features.
So you really needed that upfront specification of what the product is.
Endeavor PRD really felt helpful in many ways to me, 100% agree with them.
If you're doing regular product development, it just feels like something from the waterfall
area that gets into your way most of the time.
And Callum, I know you've had similar experience working on like a professional services team,
but also a very agile scrum team.
How do you approach PRDs?
Are they useful?
They can be.
I think there needs to be that shared understanding at the start of a project and a document format
can be useful for that, where there's general context, maybe some requirements, some thinking
from the different members of that triad before the project goes any further, really.
Maybe Scope's discussed how that comes and the format of that.
I'm pretty flexible, to be honest.
I've had PRDs, I've had things within different software, had like boards, but I do think
that shared understanding is key.
And to Johannes's point, I've also worked on B2B projects and yeah, specific requirements
from customers is really helpful because if you don't have those, you then have to go
and find them.
So if that can be present at the start, that's great.
All companies I've worked for have been so different, so I think that's maybe led me
to be quite flexible.
I was just going to say, I have interest to you, Karl, what is your favorite way of starting
an agile project?
You saying that PRD is not your favorite way, like is there an alternate asset that you'd
like to create and how would you like to progress that as the project moves on?
In lieu of a PRD, you are correct that you do have to have something that's going to
kick this thing off, some shared alignment.
I typically like to try and bring this together in a slide deck because I do like to work
with the elements that are in the system.
Again, I like to think of it as what are the market problems that we need to go solve?
And so first off, there's got to be the research to figure out what is the problem that people
are having that we think we can go solve.
And once we've agreed upon that, then we need to figure out the features or initiatives
that we're going to create to go solve those things.
Having this into like a slide deck format of, okay, this is the plan.
This is what we believe we're going to go solve.
These are the features that we want to go implement based on engineering estimates.
This is how long we think it's going to take us to get to this point.
And then when we finally have the thing built, here's our go-to-market strategy.
Here's our launch strategy because getting that software built is only part of the project
to actually launch because then you've actually got to be able to support whatever it is you've
put out there.
You've got to have pricing structures for whatever you put out there.
You've got to enable a sales team to be able to go sell this thing.
So there's a lot of different information that you have to do beyond just building the
thing.
And so from a building the thing perspective, that's where I like to keep that a lot more
fluid.
But definitely within the scope of a presentation deck, you could have pricing structures.
You could have support information and all this other information that's going to need
to be built and communicated back up to the management to say, hey, look, when we launch
this thing, here's the plan.
Here's how we're going to get it to market.
Here's our marketing bits, et cetera.
And so having that in a presentation, I think that can stay fairly consistent, but it's
the how we build the thing and what needs to go into it that I like to see be a lot
more agile.
I think for me, I don't even mind building these things in docs.
It just comes down to the culture of the company and how people consume information.
And if the company is very doc heavy, then like, great, let's write a doc.
I think calling it a PRD puts the complete responsibility on the product manager to make
decisions, to make calls, like to write it down.
And I think we should all aim for more collaboration than that.
And I know that's something, Callum, that we've talked about a little bit as well of
there's points in the product lifecycle where it's better to have designers inputs and engineering
managers inputs.
And I think moving that as early as possible is going to make everything stronger.
So having a product manager write a PRD and then handing that to a designer, it almost
puts too many limits on where you're able to go and the directions that you're able
to take because many of the decisions have been made accidentally, just naturally by
writing them down as sentences.
If the three or four or five people can get together and build that together, then suddenly
we've got a list of use cases, which is essentially a PRD, but it's a shared document that we
can all get behind and that we haven't limited ourselves by the language that we use.
And to your point, Danielle, you know, the titles do matter.
A lot of times we don't like to think that the title matters, but if somebody called
product manager comes in and like you said, write sentences that now have meaning, sometimes
some people will interpret that as well.
The product manager said, so this is the decision that's been made, even though it may have
just very well been a passing thought and you don't have a strong opinion either way.
Exactly.
Having kind of worked in a design team before reading a sentence that says we need a button
that does X, it's very easy to say, okay, I'll just draw a button.
And actually, you know, as a designer, that the button's not the best option.
It's not the best interaction.
It could be anything, but having read the sentence, it just puts limits on it.
The best time to involve other people is before you've started, like as early as you possibly
can in a product life cycle.
What do you guys think?
I think the same, I'd say, like, you know, ideally, I think it's hard doing it in practice
though.
There's lots of variables that can make that quite simple sentence seem very difficult,
but I do agree.
I think in an ideal world, having all these discussions between the tried at the start
is a good way of starting.
But again, depending on the project, that's pretty well say quite a lot, depending on
what you'll actually be working on.
You've run into some difficulties just with timing and sometimes real life gets in the
way.
Like I remember remembering starting a particular product and we started with a CLI interface.
And so there was no real thought that we needed design.
And about halfway through the development of the product, we want to add a GUI.
So okay, let's bring design in now.
And so now you've got all this stuff that's already kind of baked in and there is design
in a CLI product, whether people want to think that or not.
So now you're bringing design in like midway through and there's all sorts of decisions
that have already been made.
And it's just a little bit stickier to do that.
I feel like specifically with designers, I find it very helpful to have them involved
continuously, not only early and at the start, but especially also once we have something
implemented, because the failure mode I've seen a few times in the past is when the whole
design and engineering interaction happens in Figma exclusively, but nobody verifies
whether things in the wild implemented actually match the design.
So you might end up with an implementation that's different from what was designed or
might be the same that was designed, but it doesn't actually feel as good in practice
as it did in Figma.
So I feel like whenever engineers have something ready, that's kind of usable, ready to be
looked at, that's when I think they should stick up a flag and designers should check
out their stuff, do some testing, and then there should be some kind of feedback loop
between the two to get to the best result in the end.
I agree.
And I've experienced that working with you the last year.
It was a really good working style when as a designer, engineers are sharing progress,
because there might be things that have been implemented that are different from the design,
which the engineer might not think much of and might not be a problem.
But I think understanding why implementations might differ due to whatever constraints
there are, understanding those as the project goes along is really useful from my perspective.
I think where product inputs to that as well and something that all four of us have experience
with us doing is once you get it in the hands of users, reading the feedback from there,
whether that's feedback in the form of sentences or feedback in the form of click tracking and
understanding how people are using it and creating a feedback loop.
For me, we've already talked about this as well of when is too late to get feedback,
and sometimes it's frustratingly late.
But if you build into the flow and the process and the team's minds that there's going to be these
milestones, we're going to check in with the designer before we launch to make sure that
they're happy.
That's a point of feedback.
We shouldn't be frustrated with each other if we get some big breaking change kind of feedback
because we've built it into the plan already, and I think that's really critical.
What other milestones in a flow stand out to you guys?
What do you mean by flow?
Like the build cycle from design explorations right through to in the hands of users.
A former manager of mine once said to me, I want you to be shipping, shipping, shipping.
And I feel like that's so true because I think engineering teams should be releasing early,
often and regularly.
And releasing doesn't necessarily mean putting it out to all users.
You could make it an A-B test or you could make it a implicitly incomplete feature
preview behind some kind of setting, but really getting it out there as early as you can and
then getting whatever feedback you can get seems so important.
So I wouldn't even think of it as like certain milestones, but just trying to get it out as
early as you can and then iterating on that.
I can give an answer to your past question, Danielle.
One of the key milestones was it that you mentioned.
I think one is validation and whether that's using data to validate in the discovery process
or whether that's putting it through some prototype testing to then relay the information
to stakeholders.
Sometimes projects are ambiguous and sometimes there's not a clear solution and there's
differing opinions from different people in the team.
So having that validation from external sources, I think is key to ending up with a good solution.
And how that looks varies.
How important is it to define team structure and document processes?
And then if it is important, where do you start?
I feel like documentation is super important because it helps avoid misunderstandings about
what kind of agreements you've made within the team.
It helps onboard new team members.
It can also help other teams know how to interact with your team.
There's a few pitfalls, though, in that one of them is it's very easy to go in too deep
from the start and start documenting everything in excessive detail.
It's also very easy for it to become the top-down exercise where maybe as the engineering
manager, you're the only one maintaining the documentation and the other team members
just consume it or even worse, ignore it.
So I feel like documenting processes should be lightweight in some way.
It should be iterative.
You don't have to have it perfect from the start.
You can iterate on what you've built and it should definitely be a collaborative exercise
where the whole team is responsible for creating and maintaining the documentation.
Otherwise, it kind of just becomes outdated on its own in the end.
In terms of where I would start, I think I would start with what seems like the hottest
fire for the team right now.
So let's say you have a team where you're being flooded with customer requests, for
instance, and you're struggling to deal with them.
That definitely feels like something where you should nail down the process and write
it down as early as you can.
Or if maybe delivering on products and features is your main problem right now, then that
certainly is the process you should be documenting early on because as soon as you have documented,
that also makes it easier to notice flaws and iterate on the process over time.
Yeah, I think I'd agree with a lot of that.
I definitely think it's good to have some sort of process, even in a very fast-moving,
agile team, just like certain steps and certain responsibilities from everybody.
So everyone's kept accountable and it feels like there's a good joint effort.
But yeah, that varies a lot.
How critical is accountability?
You mentioned there that having the steps and the responsibility documented so that
folks are accountable.
What difference does it make when you don't have that accountability in a team?
I think it makes it harder to know where to put your time.
There are certain areas of a product manager and a product designer's job, for example,
where there's quite a lot of overlap.
So I think if there's a particular product manager, for example, that has a certain
expertise in a certain area, having that as part of the process for them to really push
in that area and then it could be supported by the other disciplines in different ways.
We should all play to our strengths, right?
If you know that somebody's particularly good at one thing, why would you not make
them responsible for that?
Because they're going to nail it.
That's their superstar skill.
Yeah, and I don't mean that things should be literally written down like this is what
you're accountable for.
Definitely not.
I think it's just more unwritten things.
Because of the conversations you've had, ideally at the start of projects, you kind
of know the area or focus for you, basically.
Yeah, creating that trust in those partnerships.
We start right at the beginning, we talked about how important it is to partner with
each other and when you have these free flowing conversations and you can connect with folks,
even if it's not written down, you start building those partnerships.
I know Johannes likes to write everything down and it was game changing when you wrote
it down, the team we joined on.
You just started getting all of this stuff documented slowly but surely and it just
transformed the team.
Just don't tell me how many of the docs you've deleted by now.
None of them and I call them out every single day.
So how did it change the team?
You talk about being game changing, what were some of the things you saw?
We all became very steady, which is hard to put a metric to, but suddenly there wasn't
so much chaos.
If somebody had a question, they could go find the answer for themselves and suddenly
people were self-serving.
They weren't needing each other, they were wanting to work with each other and so that
just changes your mindset.
Everybody wants to come to work and feel proud of what they're doing and feel capable and
confident in their environment.
In the case of an engineer, you're there to be the best engineer that you can be and
having to go ask your product manager what to do next, it just feels like you're then
reactive all the time.
Whereas being able to go to the company handbook, a particular document that says, okay, if
you're looking for something, here's where you pull from.
Being able to self-serve those answers is a lot more empowering and I think just going
on that journey of having an empowered team where individuals are empowered, which means
the team is just more confident and cohesive, was what I observed in Johannes' documentation.
That particular team that Daniel and I worked on, the situation was also special because
it went from being just one engineer to being four engineers plus a product manager plus
an engineering manager plus a designer.
When we started on that team, it was in a situation where there was this one person
who did everything to the best of their judgment.
Part of the purpose of documenting stuff was also to foster some knowledge extraction and
exchange among the other people on the team.
That's really cool to hear.
I fell for one of the caveats I mentioned earlier, like going in too deep and trying
to be too explicit and detailed from the start.
I think it comes down to how people consume content, right?
Where you're an engineer because you enjoy to code, not because you enjoy reading thousands
of pages of documentation.
Callum, it goes to your point as well, if designs are so easy to give feedback on because
they're so visual, everybody can have an opinion on a design.
Everybody can leave a comment in a Figma file.
Even as a product manager, I can't go into a code base and leave a comment on a particular
line of code, which just means that you kind of get into that weird flow state of like,
there's so many comments on Figma or there's so many lines of documentation for different
processes that it's impossible to consume all of that.
Which is why we have to be careful when we create documentation like this, that we're
fearing towards as simple as possible.
Not necessarily oversimplistic, but trying to be as simple as possible and not as verbose,
which I know I'm guilty of being verbose at times.
Now we have a podcast platform so you can talk to your heart's content.
That's right.
I can let some of my verbosity out here.
I know we've kind of already talked about PRDs and capturing requirements and stuff,
but just thinking about the amount of content we produce and where it lives.
How do you feel about using Figma or Zeppelin or Sketch or whatever the tools are to be that
product documentation?
Yeah, I hadn't heard the word Zeppelin and Sketch for a long time.
I forgot about these things.
Takes me back.
I don't think Figma is the best document tool, to be honest.
I think it's probably best done in a dedicated tool where everyone has editor access.
I think Figma works for some stuff, but when it comes to that shared documentation,
I prefer it to be elsewhere.
I think you have to pay, right?
If you want to have editor access and if you are on Figma, that can be quite expensive.
Whereas if you're going for a tool like a documentation tool, not going to plug any,
maybe that's a better way of doing things where there's more flexibility and more legible,
like the Figma legibility is down to who's set out the template.
I'm an engineer at heart.
I'm kind of used to working on pages of some form.
Source code files have a beginning, have an end.
There's a certain line lengths to try to enforce on it.
So personally, I kind of struggle with the aspect of Figma that you can zoom in and out
arbitrarily.
There's not a single page you can focus on.
So I find that really taxing for keeping product documentation.
It's great for like visual stuff, but as soon as it gets into writing stuff down,
I kind of prefer that to be in some kind of other system where there's more like page
format.
Yeah, it's definitely an infinite canvas that does not enforce any sense of order on you.
And you can quickly create something that even you don't understand how you put it together.
And I'm always scared that I might miss something just because I haven't found it.
So I try to zoom out as much as I can to see what might be there and then zoom in on the details
again.
Figma gives you FOMO.
Well, when people like me go ahead and put something like, I don't know, 80,000 pixels
away from everything else and make you zoom out to find all the details.
Yeah, I'm pretty sure you've done that in one of my Figma files.
I probably have.
Or FigJam files.
That's my happy place.
You have used FigJam rather effectively to visualize problems and visualize strategy
and actually be able to really kind of connect thoughts together in a way that honestly then
helped us put things into documents better than if we didn't have that visual representation
of the problem.
So we've used both in concert before.
Yeah, I think I had a manager, Johannes, you mentioned yours that was ship it, ship it,
ship it, and it stayed with you.
One of my managers a few years back said, don't show up without a prototype.
And obviously, there's examples where you can show up to a prototype.
But if you can show something and tell something at the same time, your message and your
narrative is going to land a lot stronger.
So that's why I use FigJam because you can have that visual representation as well as
the documentation, as well as the words that go alongside.
Ideally, we'd have an actual prototype in Figma, but that doesn't fit every use case
and it doesn't fit every height of conversation.
But if you're in that kind of grayscale prototype-y stage before you've got any of the answers,
then that's what I use FigJam for.
Product naming is so difficult.
It is.
That's how they came up with FigJam.
I'm just waiting for FigBird to drop FigDoc.
That would be cool.
It could solve all the problems.
I do like FigJam.
You can make good fig cakes out of it.
Let's go for another question here.
How should design, engineering, and product best engage with customers?
I think the B2B projects I've worked on, the product managers have been either
communicating regularly with customer success managers or people in that similar type of role.
Or directly with a customer.
And then as a designer, I've typically joined a project, pecked up on any of that knowledge,
and then dive deeper with discovery calls or things to aid the design.
So that's how it's worked for me in the past.
But it's generally been led, I think, by the product manager.
I feel like it's probably important to speak to a customer with just one voice.
But then at the same time, I also find that whenever I'm involved talking to customers
directly, it often feels very valuable because you're talking to somebody who uses the stuff
that you've been building.
You're getting totally new insights on what kind of problems they're facing in practice.
And so I feel like creating the room for not just the managers,
all team members to be involved with customers occasionally feels really important.
When I have shared designs with customers, it's been very useful and rewarding,
probably to second what you said, Johannes.
As a product manager, I've found that while I'm technical, I didn't write the code.
And having the people that wrote the code on the phone with the customer,
especially a very technical customer who's running into some technical challenges or
has some highly technical ideas of how things ought to be done, is usually very beneficial.
Because again, being technical, okay, great, I can have the conversation.
But having not been the person that wrote the code, I don't necessarily have the thoughts
that that person has about where to take things or about is this a really good thing that the
customer is asking for.
And so having them in the room really helps me because I love to just pass the mic to them
and let them actually talk through the problem with the customer.
And then based on that conversation, figure out what makes sense from a product perspective.
It can also be super impactful for engineers to create that kind of customer mindset because
it's very common for engineers to be kind of averse to customer interactions because
they often see it as something that gets in their way, which I can totally understand.
But then again, it just reinforces the purpose of why they're doing their work.
So I'm really a huge fan of getting them involved.
I think when you're talking to customers, you can understand their environment.
And so many small things happen through the course of designing and building a product
that we don't always explicitly talk about.
Performance is one of them.
Unless your performance is really bad, it's often forgotten.
It's so critical to the customer experience that understanding the environment that they're in
and maybe what Wi-Fi bandwidth they have or how quickly they need an answer to their question
or how quickly they need feedback can really shape that design, both from a visual design
and from a code design perspective.
But it takes a really, really good product manager to remember that you have to have
a conversation about performance for every single product.
So I think engaging with customers directly, every part of the triad pulls some of those
conversations out where a product manager might have forgotten to bring them up.
I think the other aspect of working with customers that I just thought about is you
probably want to have some kind of SLAs for the interaction with them.
So let's say you have a prospect maybe that's brought to your team by pre-sales.
It's probably a good idea if your team has an SLA for what your
usual response time is to that request.
And I don't mean kind of implementing it.
I mean just doing the technical design, planning, effort assessment to then
aid the decision of whether or not you're actually going to engage with that.
It might be similar for cases where customers report bugs to you.
Having an SLA there for triaging the bug would probably be quite important.
Yeah, taking five years to tell a customer no to a bug that they filed is not a good experience.
I can tell you from personal experience that five years later, they're not happy to get that no.
We've all closed a bug five years after it was raised.
Five days later, they'd have been more happy with that no.
They wouldn't have been happy with it, but they'd have been more happy than five years later.
Well, Danielle, do you want to move on to our final question?
Oh, you do that every time.
We never write in the document, Danielle's going to come up with a final question,
but every podcast that we've recorded, Karl's like, the final question.
I always forget what it is.
Do you really?
I can write it in the document real quick.
No, no, no, I got it, I got it.
I just forget that it's coming.
Final question of the episode is usually a fun one, just to get to know you a little better.
You can wake up any place tomorrow and do anything for the day.
What would you choose?
I think my answer is going to be quite boring because I think I would
like to wake up where I am with my family and be able to spend the day with them.
That's an excellent answer.
Not boring.
It's excellent.
Sounds like you're winning.
Yeah, it sure does.
Callum, what do you reckon?
I would be waking up somewhere on Hokkaido, which is an island in the north of Japan,
skiing some powder, ideally.
I was there for a ski season when I was younger and haven't been back since,
and it was like the best time of my life.
And as it's winter in London and miserable, I'd like to be skiing.
It's the best way to spend the winter.
So yeah, that's my answer.
That's pretty cool too.
Well, thank you both for joining us today.
Yeah, thank you very much.
This has been Productly Speaking.
Thank you for tuning in.
If you like what you heard, subscribe.
Make sure you don't miss any episodes.
Also, share our podcast with your friends and anyone you think might enjoy listening
to an American and a Brit natter on about product management.
I don't think you can call it nattering.
I guess actually we did stay on topic and it's not technically nattering.
Exactly.
Well, what did you guys think?
Leave us some feedback.
Make sure to visit us at www.productlyspeaking.com,
send us an email at hello at productlyspeaking.com,
or join the chat on matrix at hashtag productlyspeaking colon matrix.org.
Thank you all again.
And until next time, cheerio.