When the engineering partner would come to the conversation with talking about how other products that are successful have approached that and what choices they made as opposed to just talking about the technology in the abstract. The business aspect of it, how it helped drive business results for other companies that are in similar markets or adjacent spaces, that's something that's super valuable because it shows that you are thinking about the technology just not for the love of technology but in the business context and in the appreciation of how the technology decisions drive.
Hello and welcome to the Engineering Leadership Podcast brought to you by ELC, the Engineering Leadership Community. I'm Jeremy, founder of ELC, and I'm Patrick Gallagher and we're your host. Our show shares the most critical perspectives habits and examples of great software engineering leaders to help evolve leadership in the tech industry.
If you want to reduce friction and create better alignment between product & engineering, then this episode is for you. Hubert Palan, CEO at Product Board, joins us to deconstruct great collaboration between engineering & product and in this conversation we cover elements of healthy collaboration, common areas of tension, steps to align your teams on product vision, how to advocate for engineering priorities, plus in this conversation we talk about how you, as a person,
can contribute more to defining the product vision and strategy for your business. If you've ever sat and wondered how can I do more to define the product vision, this is it right here, this conversation. Let me introduce you to Hubert. Hubert Palan is founder and CEO of Product Board. Hubert started Product Board when he saw hole in the market for a dedicated product management platform.
So Hubert really lives in the user persona of product managers and engineering teams all the time, which is why we wanted him on the show to help us demystify this whole experience. Before Product Board, Hubert was VP of product management at good data and a management consultant at Accenture, enjoy this conversation with Hubert Palan. I just want to say welcome here. Thank you so much for joining us on the show. How's your Tuesday going? What's going on in your world?
Happy Tuesday. Thanks for having me. I always say happy Tuesday because I never know where people are in the world and all the time with the data. It's good. It's a busy, it's a busy time overall. Plus I have a baby number three due in a couple of weeks. So there's a certain level of elevated anxiety. Oh my gosh. It's positive. Well, congratulations on the incoming baby. That's a special moment for the family. Thank you. Thank you.
Well, to set some context for our conversation, I know that we wanted to take a little bit of a deep dive into the engineering and product collaboration and you know, I can explore that a couple different ways and the goal being to help transform the relationship between product and engineering, which I think more than anything is probably more stereotypical.
Like the cliche is like, oh, there's this tension between products and engineering. I'm hoping you and I can transform that a little bit. But the big why and what I'm interested and really excited for about this conversation is that at product board with what you're doing. You've built a product four pms. And so you really are deep into the minds and motivation of product. And so I'm just excited to chat with you and to get into some of the translating what is going on in that world.
What's been your experience collaborating between engineering and product and what are some of the key elements that have contributed to that successful collaboration. Yeah. And you mentioned a little bit and you know, where product board is a product management software, product management platform. But you know, at the end of the day, the way I always thought about the craft of creating digital products that are extraordinary.
It is about very tight collaboration and shared understanding of who is the customer or what are the pain points or problem. And then what are you going to do about it, which is by the way, fundamentally what product management is about, you know, what are the project management of managing tasks in milestones is like, who's the customer with every pain points.
And to your question about the collaboration with engineering, at the end of the day, the more you understand the problem, the better solution you can device. And so while the specialization is needed. And while the core focus of the product management role is the problem and the customer understanding and kind of the market understanding and engineering is much more about the solution and building the best possible product that is architected right and scalable and performance and usable.
All that in the right way, it really needs to be a very tight union in the absence of understanding the problem, your risk of building something that nobody needs. So I say it's critical. And you know, it's I would add to it. It's not just engineering a product. It is design engineering a product is a triad.
But then across the entire company, the more and closer understanding you have of who is the customer, what are the pain points and where are you doing about it, the better ultimately the execution is going to be not just on the product side, but on the go to market side as well, right, you need to get it to the customers.
I really like what you shared about it's not just engineering product, but it's about engineering product and design, but then you extended it further to it's the entire company. Probably the next question to zoom out a little bit like how do you think about translating things like the problem or like to create a better understanding of the problem to other elements of the business beyond maybe just like the engineering product design triad and what is that extension look like.
I mean, so it is the elements right is like who is the who's the person who's the audience and it can be business is right doesn't have to be individuals, but having a very, very clear understanding of the both the demographics, the scriptures as well as the behavioral and the needs that segment has is critical.
And so I mean, there's multiple tools right like in different parts of the business called them differently and on the sale side, we have ideal customer profile and marketing has personas, especially a lot of buyer personas and designers have user personas engineering kind of relies on what comes from design product management.
Ultimately, it needs to be a representation of not just the user, but the market and it needs to be clear to everybody that there's very few products that have a very homogeneous user base and that every conversation that you have should really start with clarifying.
Okay, who are we talking about and it might want to be obvious it might be kind of people in the consumer world you might think about like okay, is it a mom with kids or is it a teenager or is it a retiree right like you know obvious demographics. But if you start thinking about people in the context of what is it trying to do that suddenly unlocks very different dimensions and on the B to B side, it's not just like small medium, you know enterprise companies.
I'll give you an example in our case, you know, we early earlier in the day start about okay, what kind of a product is a company building? Is it a smaller large company? Do they have one product or multiple product?
Is it digital first or digital transformation company? Is it B to B or B to C? Is it a company that's kind of high on product maturity and bought into lean startup and understands the customer centric is it the framework or is it somebody who's kind of more old school type of a thinker or leader in the role.
All of that you need to have the conversations and you need to qualify it you need to have artifacts around it you need to grow chose and make sure that everybody understands it the same way you need to facilitate questions you AMA's like all that needs to happen. So let's say it doesn't get everybody on the same page.
Absolutely. I think the the be clear that every conversation to start with who are we talking about it doesn't happen enough like that almost seems to me that should be the prerequisite agenda item at the very beginning when you're entering into those types of meetings like step one who are we talking about then steps.
Two through X. Yeah, it's it's it's kind of like we always talk you know and in pregnant engineering when you're doing prioritization is like okay what's the most important thing like what's going to move the needle most but for whom yeah and it's like it's very very different.
Well, like what are you optimizing for and even kind of characteristics and sure that something we could get to her but I really trying to make sure that the current existing product with the current feature set is really really good or are we trying to add new adjacent use cases or problems and you know innovate and add some new functionality or are you trying to make sure that the foundations are scalable and that you don't have
that and you know have is a bit that you know like all that needs to be put in front of everybody before you can start talking about value. For what trying to do what and then you can have a conversation about prioritization.
Absolutely. I think this is a good a good opportunity to dive into some of the areas of friction that you've identified between engineering and product and so is running if you share maybe from your perspective like what have been some of the greatest areas of friction that you've
observed between engineering and product and I guess where any of those surprising to you. I mean who's calling the shots is kind of a kind of a big one and it comes you know often from the DNA of the company and kind of how the you know maybe even back to the founders and who has the most influence is the engineering or is it the product manager
or is it the business side right it really depends on the on the DNA of the company and so I feel like clarifying what the responsibilities are and who owns what kind of like the big picture like who can make a decision what's going to get bailed or who can make a decision which portion of our
capacity is going to go to innovating versus eliminating tech that or you know strengthen the fine foundation so it's kind of on a metal level that that understanding who owns what and even on a lower level like on the individual
level even at our company we've had conversations like also what should an engineering manager or the team leaders is the product manager and who's in charge of the Scrum management or project management in general or who runs the ceremonies you know we try to basically say like hey this is going to be the job of product manager for this stuff and so the engineering manager is going to be for this stuff and then we realize that people are people and that don't never not everybody fits the same
as the manager and that it actually pays off to you know agree on the principles and agree on the outcomes but then be more flexible and maybe one team you know maybe the engineering manager is is is better to run the ceremonies and be really the kind of the the controller of the pace and the really driving the execution and in in in in our situations is the product manager who's going to be doing more of the kind of project management in addition to the
work management which we talked about right who is the customer what problems are we solving and so on while this is a friction just need to be flexible. The another thing that I can think of is kind of what is the process and the unification of process and this is kind of interesting because on the engineering side I feel it over the last what 20 years you know of agile methodology like the the unification of the engineering aspect of the delivery kind of happened and you know people are more
unifying than aligned but frequently still in the product side the different product managers have very different ways out to prioritize they choose different criteria as they use different tools often still everybody has different spreadsheets or even you know
whatever task management systems and there's little unification and then it hurts the entire productivity of the entire team because what happens is that you need to start rolling up the work of the individual teams in the organization right to the higher levels of the
work and you need unified process across product and engineering and design again as a triad in order to eliminate a lot of the friction and kind of confusion with the who's calling the shots area I can imagine if that is unspoken or not communicated huge area of friction oh my gosh so you mentioned clarify the responsibilities of like who runs the ceremonies are in some of those different elements like what is the
successful conversation look like in that area where maybe the decision maker is unclear like in your mind how does that go well I think the success is when you are clear about who's driving what initiative and who's the decided right but the reality is it's difficult because there's frequently people in the organization and especially the start of world where you just have more context that other people
because you've been around the longest and you thought about the problem the longest and you know obviously the founders are natural centers of that but as the company grows there's other people in different domains in different areas and so the question is like how do you make sure that you really take advantage of the knowledge ridder than reinventing it and kind of you know just delegating to people who just started or you know
don't don't have that deep away context and I but I feel like you need to do it in a way that it that it scales and the journal blocked and that it's not a bottom like that this person has to be involved in everything and I like me tell you it's been a challenge for me as a founder who feels like obvious that I have the biggest
and everything how do I let go and how do I delegate but I feel like what you can do is a design a process where you have the opportunity to participate but then also if you don't it's kind of it's kind of understood that hey there was a there was a opportunity there was a touch point there was a you know review or some feedback session and
few skipped it these kept it and you know teams going another thing is that one of the teams that I'm working with we put together kind of a tiger team that I'm working with on the website and we have a decision log and the engineer who runs that he said like hey how high of an impact decision it is and what is the is it the one way to they already Amazon kind of screen and we determine that and then if it isn't then you know maybe I don't need to I don't need to provide
in Poetoria I'll maybe years later and we can reverse it if you know if I have that context that was important that we change the decision and so on but that it's a structured conversation.
Another question related to this particular one so you also talked about like differentiating the responsibilities like what would be like your preference for how these responsibilities are split between you know engineer manager or tech lead in a product manager you mentioned you know maybe an EM drives the pace but the PM drives more of the project management like the
customer Paypoint representation in your preference like how do you see those split in a way that you feel works best most effective maybe for you and product board.
And the key is product management is not project management right and product management is really understanding like I said I'm going to repeat it's his key who is the customer what are the pain points needs use cases jobs to be done whatever you want to call it like what represents the need and then the product managers job is like product manager owns this if you as an engineer show up a
product manager should be able to tell you this is great or this sucks you know basically on a scale it's not black and white but that's the primary job of product manager then second there it to it is is there big enough market if you build this it might be great it might be amazing for this for the segment of the market but is it big enough and can you build a business around it and so that's that's the
product management responsibility and then engineering is hey let's make sure that the solution is amazing that it scales that it's performance right it has all the aspects of security and designers responsibilities the usability the kind of seamless functionality as well as emotional aspect of it is it delightful you can kind of carve out this
very clear but they're like who manages the project aspect of it oftentimes the product manager is more the project manager but that is my point is that it's not really the goal it shouldn't be the focus and so I I actually would say like it doesn't really matter who the project manager is as long as there is one that's on top of it that has the discipline that's able to communicate probably often it is the product manager but doesn't have to be the engineer is organized you know
loves to talk about things that are not just the solution right but you need to manage the project of everything then it can make sense also seems like a big opportunity for like leadership growth as well to take that part on and drive and drive the initiative absolutely I mean absolutely right like because you know people say in the industry that a lot of future CEOs come from the product management role and I would argue that it is the combination of the
market knowledge with kind of execution abilities and so if you want to be in the leadership position from the engineering perspective like you should take on this project management execution management of what the team is working on or a bigger part of organization because that's expected from you is if you want to be a CTO or CEO one day one of the the narratives that is sort of occurring in our community is around sort of this mandate to do more with less to figure out engineering
efficiency and all of those types of things and so when you're talking about sort of the engineering process disconnects that can happen I was like ah this is a huge area of probably surprising inefficiency to have sort of these like separate processes to develop and and ship things and so I was wondering like from an engineering process perspective like what is like a good ideal state look like in your mind like is it unified tooling or is it engineering
process to design using different tools but like sinking and aligning on like all the different elements that they're trying to track like in your mind like how does that how do those like the engineering process or product management process sort of come together.
Yeah, I I'd say that I mean tooling is important the process and kind of the whole the whole tech stack for sure but it really is downstream of alignment and clarity around the product vision and strategy and the broader contacts that needs to be shared so I would
start I would start there and it's really kind of to the early conversation about making sure that the understanding is shared it needs to happen across the entire product design engineering engineering product design R&D team and there is the role of the leadership products or you know
the CTO whoever is calling the shop the shots to be very crisp about okay where are we going in the long term but then don't confuse the long term vision with the immediate focus and kind of the milestone along so it along which we are going to go there and be as crisp and clear about okay what are we trying to achieve at the at any given point in time.
A lot of teams kind of confuse the vision with the immediate steps and you're like oh we're going to be this big company that has all these things and yeah maybe five years from now maybe 10 years from now maybe 20 years from now but like we're going to build tomorrow and you need to be very focused right need to be like okay for this segment for this need this is exactly what we're going to build and then next we're going to expand and we're going to see this five more needs
or you know maybe need for more different segments like it depends what your strategy is you can build a company that is very deep for one segment into a lot of use cases where you can build a horizontal company like notion right that satisfying a lot of use cases for air table that's a lot of use cases where many different audiences and so that conversation is critical and then in terms of the the process kind of what are the dimensions and for example we have clarity
over investment buckets that you use to measure how you spend your R&D capacity meaning what percentage goes into improving the existing functionality for the existing use cases of your core product right like what you already promised to the customers like is it good enough are you really meeting the bar of the expectations and if not like how much investment is going there to fix the usability to fix gaps in the core experience to make sure that the
the core is really solid that the unit economics are really really in the right shape and second aspect okay if you have that like what are the next things on the differentiators that you're going to build in order to be really ahead of competition and so and then technical foundation customer specials if you're expanding to new segments and you should have again agreement and alignment what are these buckets because that is the confusion between product management and engineering
oh you need to build this new feature well way the minute we have this technical debt and so like you know hey where do we meet today it's all about our life if if engineering product design teams are not driving product engagement it's that you're doing
something wrong and so this is challenging how do you measure how do you measure breaking engagement it's always like oh how do you measure the value and how do I hold engineering product design to be accountable there should be a leaderboard of features just like you have a
leaderboard with salespeople who you know deliver revenues like okay your your feature how much engagement that the drive into last 30 days and you can do to the days now or third days post launch and then show it to everybody well then did you make by launching a feature and and again for who and so on right there you need to be more nuanced but long answer I don't know if I have three different angles to dive into right now I wanted to jump into what you're mentioning about the product vision
in that area of alignment because one area where I feel like I struggle with is breaking down a long term vision and starting to figure out sequence or short term versus long term milestones and what that looks like how are you going through the process of developing the product vision and then breaking that down like do you have specific
questions or prompts that you're reflecting on like what does that process look like for you I mentioned the dimensions along which you described the segments and I mentioned B2B2C and one product multiple products and you know modern product management all to the
full product management you know what whatever dimensions are in your world but start there because that is the foundation for understanding the segmentation of the market and basically what you want to do is to make sure that you identify the smallest or like the most concentrated pain for a customer segment that can be small but you need to have a line of sight to where you want to go later and so I'll give you I'll
give you a very simple example when Salesforce started as a CRM product you know build obviously now it's a massive company that satisfy sales and marketing customer success service cases whatever but when they started they satisfy needs just of the sales team and then within that even was like is it a sales wrap versus sales manager versus head of sales versus sales operations and the more nuance understanding you have of that as part of the vision right like you
articulate like look this is the market this is the process this are the needs there's all these different types of users and they have different needs and we want to build at one point like product board wants to build a platform that's going to be at to end and third product management life cycle and all these people there collaborative not just product managers the designers and engineers and all the business take over since that's the vision that we're
going to start with the individual product manager at a B2B sauce kind of you know digital first company that has a relatively low complexity of the product that's the B jet that's the segment and so that narrative was part of the vision was like draw the picture not just not just tell people hey this is what we're
going to build and for everybody but like me nuance about how does the market segment and then when you kind of describe this big picture then you can go and say this is the sequencing and you know we want to play here we don't want to play here maybe next year we're going to expand into the new case and you know then the scope is going to evolve but that's not what we're going to do now and so the salesperson shows up and says like hey I have this feature request from
this customer and it's like super important and it will help us close the deal that's amazing but is it for the segment that we said is the focus for you know whatever this period right for this year whatever your strategic planning is and if it isn't then you say thank you
it's so wonderful that such an insightful thing and we understand your opportunity but sure you can see if I show you this matrix with the segments and the needs that we are focused right now because 90% of your opportunities is quarter that you have fit into this bucket and what you're saying here I understand it's a big deal but it's an outlier and it's so small you know in the aggregate or doesn't represent the broader market opportunity this conversation is critical if you don't
talk about what you know off but don't focus are not focused on are not going to build right now then it's all like a wishy-washy hey vision for everything everyone one day and so on but like what's next what sequence the process that you described there of you know you're talking about the matrix of saying we have 90% investment here like all of the deals that you've been navigating in that area like you've closed at a much higher percentage and like this one is a small use case like that
conflict between like engineering or product and maybe like the quote unquote business side or like marketing sales or whatever that happens all the time and that's such a hard thing to bridge because like you have people that are motivated by like getting the deal closed and then you have people motivated by kind of different elements in terms of you know how the that part of the organization is built up I just the practice that you laid out there I thought was
was really great even bigger probably friction is between the existing customers and the new customers right because on the market sizes like oh we need to build this new thing and then because sales doesn't see the existing customers customer success and support season existing customers and they're frustrated that there's gaps right was like the job of the product organization is to balance that you really need to have the portfolio balance like where are you
building for the existing customers and improving the more you can articulate will revenue is tied to it or what kind of you know impact it can be some strategic elements right it doesn't have to be just like directly tied you know the new air or goals or whatever it's more complex than that but having that conversation that that's the job of the product leadership and it is not just the product leadership because engineering needs to be the one
who's going to be banging like remember the skyscraper that we built that we or live in it's actually the pillars are not going to the bad rock and it's like the Millennium tower in San Francisco this declining and if you don't go on and fix it like the whole building is going to fall so like we should probably fix it if you want to continue building living here and even more so if you want to build 100 builds and put them top more 100 more stories but that's
that's why it's a collaborative conversation and you need to tell that to the business side as well. So go back to product vision from your perspective for engineering leaders that maybe want to get more involved in participation in like developing that product vision like how might an engineering leader do that like what might be your recommendation for an engineering leader to get more involved in like the product
vision side of what's going on. So I'll tell you what I don't know if I have like a silver bullet you know he's an answer but what I appreciate is a founder who's like I have a product background right so I can product founder even though I have masters in computer science but like you know my co-founder was the CTO and has been running that but what I always appreciate is in those conversations is when the engineering partner
would come to the conversation with talking about how other products that are successful have approached that and what choices they made as opposed to just talking about the technology in the abstract.
The business aspect of it how it help drive business results for other companies that are in similar markets or adjacent spaces that's something that's super valuable because it shows that you are thinking about the technology just not for the love of technology but in the business context and in the appreciation of how the technology decisions drive the business outcomes and it's hard because like always these trade-offs right and like even else we build historically very front and heavy
application because you know hey let's build it on Heracool let's you know massive payload let's have everything in the browser and that's fine and it's going to be super responsive everything and we'll just you know single the clients together right and it's like very light server and so on and then the price you pay for being successful and having customers that are massive companies like Kruger retailer or you know like Volkswagen or Zoom is a big customer Lars is that just a lot of
data and so you basically cook the browser in that technology right and so like okay maybe let's rearchitect and you need to go and you need to rebuild everything and move it to the server and have a much more much lighter front and so on but again my point is that the conversation needs to be
happening kind of between products like where we go and what are the expectations and engineering should be just sitting there and saying like hey tell us what to build but how do you think about the evolution like these questions and I saw that this company have gone through this and sells
for her to rearchitect right and then that's a head to rearchitect when I've already scaled and you know even I just read this blog post that linear the new cool kid on the blog in the engineering ticketing management is having performance issues because they have everything in the browser so like
you know that kind of an input and conversation is just a hugely valuable and gets you seat in the conversation that's the respect as opposed to just hey you know which which specific technical you know decision we're gonna we're gonna do an abdicate on the understanding of the problem and the business opportunity that don't do that. How to get respect in the conversation I love that headline.
Yeah and you know that doesn't mean to you're the experts right just like the product people are not experts in technology but just like the appreciation and listening and showing curiosity about that aspect of the work because I mean then you're more relevant near answers in your contribution to the overall success right you're a collaborative partner as opposed to just hey you know I'm the best engineer just tell me what to build and I'll fly go.
Curiosity is a pathway to generate respect and mutual understanding that I love that. So I'll talk about conflicting priorities related to like product vision when there's misalignment here. How do you handle like conflicting priorities when maybe technical feasibility and that product vision maybe at first first surface level don't align like what is that like what I what I mentioned about the framework that is critical aspect of it to kind of explain and
and you know sometimes I would say that don't assume some of the basics that people outside of engineering understand like for example what is the technical debt just like that conversation what is it is it the mistakes that we made in the past or is it the intentional cutting corners that we've
done with the technology knowing that it's a debt which you know in my book that is the definition as opposed to the we screwed up on my mistakes and how we need to go and course correct that's a different category and it's you know both happens right it's inevitable but just like
having that conversation and explaining that to your partners whether it's product or whether it's the business side be very clear about hey we will need to rebuild it but like really keep a log of it to make sure that you know that it is piling up just like the financial debt
right like you need to be diligent because you might kind of know it and you might you might have it in the back of your head and you know as an engineer the code base and you're responsible for that piece and you know it but nobody else does and if it's not transparent if it's not
shared if that you know is not top of mind like it's so difficult to facilitate a conversation and you know resolve that conflict and I'm sure that people have seen it right like product management is pushing new features and engineering is you know under the pile of rubble trying
to like keep the house working but it's it's partially communication problem because you are not articulate clearly where the problems are and what's happening there and sometimes you need to drag the product manager to the basement to show them the rotten you know foundation
pillars or whatever the dry road that you have to kind of like understand that so yeah the framework and the communication and then the conflicting priorities like oftentimes it's very difficult to kind of explain you know on the analogy of the skyscraper okay so how big of a
house are we building here really and you know you're not going to start the startup from day one building a massive foundation because you're you don't even have money to finish the foundation and then you start the building right you unfortunately you don't need to build a tent and then the house
and then carry down and then go and build the skyscraper and you know then keep building on top of that but like what are the inflection points that's something that you should talk about and the engineering partners should be able to clearly articulate where the limits and you and again
communication right the storytelling and use the tent look this is I know that you think that we can cram 100 people into this tent but this tent is really for two people it's great if you sell more of it it's like the DC black ray movie I haven't seen it yet no I just watched
the exact couple weeks ago and they talking about the capacity of network and you know how ultimately it will break sometimes you can push it sometimes you can have a breakthrough that just allows you to scream more people into the tent or inflate the tent or whatever
right and increase the capacity but oftentimes you can it just like you just then need to stop everything and go and rearchitect and so again that needs to be a very intentional conversation of what are we what are we architecting for and an understanding of the limits and then
when ahead of time we need to start building the second generation of the architecture that's going to be you know able to support the next generation of the business goals but oftentimes that doesn't happen and then everybody's like surprised and the business decided oh how come that it's
so slow and how come that the browser you know can handle that can just like you know buy more hardware better whatever I was going to say I hope people borrow the tent and skyscraper metaphor especially in the realm of re-architecting and understanding the limits of what you're building
for I think that the metaphor of telling some of these stories is so powerful regardless of you know the depth of explanation behind the technology that you're working with that can be really powerful well that kind of answered my next question was about like you know how can you best advocate
that some of engineering's most important considerations are addressed and it's like what you said take the time to explain sometimes you need to like take people down to the basement and show them the ugly things and then also you know use the metaphor use the metaphor to explain what's going on I love that yeah I know it's you know like it's hard right because it is in part art and the reality is that you might build a tent and then decide that next to the tent you need to build a completely
different one or you know different house I guess like you're you're placing bats and especially the bigger you are the bigger portfolio you manage and you might have multiple products and that's like which one are you you know funding where you're investing it gets it gets complex
very quickly but having that framework and having that understanding that you need to have the conversation which is really like you know the role role of the leadership is to define the frameworks that create the incentives and that sets the stage for the conversation so like every
product manager if you're prioritizing a feature should fill out whether it is going to help existing users or new users is it going to help with expanding to new segments is it a customer special like that that should be filled out and on the engineering side as well right like hey rebuilding
this is it kind of a category of okay we build it this way it's not going to scale it's like this this is a temporary solution it will help you validate something or it will scale to certain aspect but then you know we will need to go and we will need to build it differently or hey we're going
to build it but it's like a custom build thing we understand that we're building platform here and that we will need to build it into a more modular Lego like pieces that can be used later down the road but there's an overhead of designing it you're never going to get the
beautifully sculpted marble statue out of Lego it's the Lego you will see the pieces right but it's like you can build a lot of things from the pieces and so that conversation I go again about the objectives and what are you optimizing for needs needs to happen I build the metaphors
you can tell I love metaphors it's my whole life in this world like I struggled to explain it to people who are you know even people in my personal life like what is this pregnant woman like what are you guys doing like what is this company and then you can imagine that you know
speaking through the media and journalists so I'm like what is this product management thing I'm like you guys are a unicorn company like watch out what the hell are you doing so like you don't have an option then to like tie to something and people know in their real life
well one practice that I heard of so Jan Chong VP of engineering at Tally's joined us she and she's done stands at a number of other different places one of the practices she introduced in this conversation was like her and her team brainstorm metaphors they do
like a whole metaphor brainstorm like the whole subject of their meeting to help translate some of the the harder parts of engineering to understand to different parts of the business that maybe have less context and don't quite know and so like that practice to be like I
love that and so if you're looking for a metaphor jam partner Jan is one of the best best out there most definitely you have emphasized through this conversation that communication is critical between these different elements of like of the EPD triad
so you're talking earlier about you know have alignment on like the different buckets of investment that you're that you're focused on I was running a few show more about like how do you facilitate communication between engineering and product management teams like are there specific conversations
like including this having alignment on the buckets that you're investing in are there specific conversations that help facilitate that great communication like are there certain ones that are consistent certain ones that are as needed like what are some of those conversations that you found
like absolutely critical you know we have regular meetings we have regular triads like the different but everything is in the triad in the EPD so to make sure that that is the unit it needs to be super tight and on all the levels and I mean you know and it is challenging right and there's even disparity between the size of the organizations because the engineering is in terms of headcount the biggest one you can see a ratio of like one to eight
product managers and you know less than that or like a high ratio for designers and so there is the natural kind of gravity of a human volume right like that you have more people in engineering and so for example when you're doing re-orx it's like oh we need to engage all the engineering managers
because they're the team leaders right and they have all these teams in the product managers like there's very few comparatively speaking right so you have much less organization and it's like well yeah but you should involve them because they're on the same level in the triad that requires the discipline on the communication side to make to make sure that everybody's aligned from the business versus the EPD perspective that's that's interesting one and it's probably the CEO's job
is to like bridge the you know business strategy overall and make sure that that gets communicated regularly and that you have office hours and AMAs and that all parts of the organization can ask and obviously from EPD is going to be more technical than from the business side
then you need to keep repeating it and make sure that you do road show and make sure that that conversation is just you know it never stops and you need to repeat it just because people don't remember things because people don't pay attention but also because you have a lot of new people
right if you're the company you have a tradition company scaling and so it's challenging because it's not natural for us humans to just like go and repeat the same thing especially if you're like very curious person and you're kind of hooked on novelty
like oh I'm gonna go and I'm gonna tell for the 15th time what we're doing what the platform and then the challenge is that you're sitting in front of an audience of people from different cohorts we have different contacts and so like how do you make it you know some people
heard the joke that you're saying in the metaphor or the 10 times and others aren't you to it so it's like you know how engaging is it so I don't know if I have answers like maybe you do cohortage right maybe you have like hey who's been around what and maybe you do kind of like a train the trainer
and you try to engage the original gangsters to share some of it on on behalf of the leadership you know I'm kind of like do it is it participatory collaborative exercise and collaboration I've one more question before we transition to rapid fire
this sort of relates to like the requirements gathering side or a rather getting input from engineering on product strategy or defining the product or defining some of the requirements like what are some of the steps that you find are in the process of the process
of either requirements gathering defining the product or the division and strategy side of product sharing information in humanity is difficult and often analytical people like engineers like you want to go to the source and you want to hear it kind of from the horses mouth right and so anyway like you product managers and you want to go to the source and you want to hear it kind of from the horses mouth right and so anyway like you product managers you're telling me this but like you know
let's go to Dr. Customers or like let's validate everything right even the even the problems so it's kind of a balance between how much do you trust the person that's standing in front of you and telling you like I already validated the problem or like I need help on the solution
and like you know if you go and we invent everything and yeah we're gonna get to absolute perfect understanding that's shared across everybody but it's also the slowest way to get there right it's kind of like you just graduated from college you just they would give you a patient and you would say
and they would tell you congratulations you're a doctor now and like on your on your own go and figure out how to solve this patient without like talking to the senior doctors at the hospital who have years of experience and you're like you're inventing everything like well that's not probably the best thing that you would do right and so just in the in the business world also you need to rely on the experience of other people at the company
you have the context and you don't always go to the to the root cause anyway my point is that how do you balance that with the need to be exposed to it with the need that if you show somebody transcript from a call with sales people or you know user research interview and people hear it from the from the source that you just believe it and you trusted more I remember talking to Amy Bunsell who's a SVP of product that auditors she owns
product that auditors she owns auto cadets as the product in my my my my sellers and she said like we went and we recorded little like short movies about the customers to explain to the business and this is auditors great company so the resources but like they they literally created like production to explain the emotions and explain the customers and the challenges that they have with the with the product to the rest of the organization who were not this deep in the product
right to to create the empathy or to leverage the empathy and kind of like help them understand so I you know long answer but like you need to balance it exposed people to the ways of the customer and make them part of that don't don't heal them don't just keep them as I like hate it's my job as the product manager to understand the customers
but at the same time you need to foster the trust so that people don't go and they don't want to validate everything because it's just slow and you don't have time I mean you said it create a little time resources budgets cuts like macro depression in tech it's like a massive recession right in tech we've had recession no doubt
so that creates even more pressure on moving fast and moving fast means that if you're fighting war you're a soldier on the frontline guess you don't have the time and the the the ideal ability to get all the information from all the parts of the battlefield before you're going to go and you know fight if I don't the frontline like the general is due and I know that it's uncomfortable obviously the extreme would be that you're building a feature factory and don't
question anything just I am telling you what to build like and that that's not what I'm trying to say I'm just saying that they needs to be a balance because otherwise you're slow your idealized everything understand everything and it takes you forever to figure it out you were I know we're just about a time I've got four rapid fire questions if you have a few minutes to go over yeah okay what are the questions
number one what are you reading or listening to right now I do a lot of podcasts I just finished this book called out live which is non-tech but it's how to live hell stay longer live and I as a result exercise more and eat more protein and go and read the book just a lot of great hello great insights and I you know I read business books I tried to learn from the best
people so I often go and I also I want to see people I want to I often I don't have the time much but like I often have the desire to not just listen to podcasts but see the people that that are talking and go YouTube or you know podcasts that have videos like what you guys are doing so I feel like it gets me better inside into the person and their passion and emotions and who they are question number two what's a tool or methodology that's had a big impact on you
I mean the most recent is Figma I love it because you know I used to in the early days you ski note and then with the sketch and you're before then you know the design side I just love how easy it is to do everything collaboratively and Figma love it what's a trend that you're seeing or following that's been interesting or hasn't hit the mainstream yet
the most recent thing in the area of AI is thinking a lot about you know not just the large language models you throw question at them and then they they generate answer based on what they were trained but there's there's this whole conversation about we have one model or are you going to have multiple models that are specialized and is there going to be like an Uber model and I've been thinking about it all depends on our ability to design models that are going to be curious
because if models are like humans then it would aim at having one Uber model because that model would just learn from everything else and no other models would survive but if you don't succeed with the kind of self training and kind of inciting curiosity then we would have multiple language models so I don't know if it's a trend but if it's something that I've been thinking about a lot because you listen to different I listen again to this podcast marks
I can break and you know mark and recent and different opinions so it's a little chaotic I'm trying to be like very the new you answer to this question but I think it's a big one I think it's a big one and it you know what's interesting learning and having more interest in the artificial intelligence I feel like it to help me understand human brain better which is kind of ironic but it seems like you know the ability to learn
and how the neural networks work and I had neural networks when I was in 2001 getting my masters you know the math aspect of it but now it's just like oh this is how I can retrain my human brain because I see how the LLM are being trained and you know interesting last question here is there a quote or mantra that you live by or a quote that's been resonating with you right now I have also my mantra personal but I like two aspects and that's to live my life with love and activity and love meaning
I mean different types of love for different types of audiences it's all about segmentation and like my my life is different as my co-workers but then the activity is like how can I live my life productively and make impact and drive innovation and kind of minimize entertainment and at a productive time only to the extent that it's contributing to my physical and mental well-being but then think read contribute teach my kids that's how I live
A powerful way to close this off thank you so much for joining us on the show and doing a deep dive into the world of product design conflict prioritization product vision and all of the like we really appreciate it was a ton of fun thank you for having me if you enjoyed the episode make sure that you click subscribe if you're listening on Apple podcasts or follow if you're listening on Spotify and if you
love the show we also have a ton of other ways to stay involved with the engineering leadership community to stay up to date and learn more about all of our upcoming events