When you start doing some discovery, you start talking to customers when you start measuring whether the things that you think will happen will actually happen. When you start running lightweight tests, when you start doing prototypes and usability tests, then after some time you're like, how did I ever not do this? How did I just turn out features and throw them into the wild and just go like, I guess this is fine? Because when you do these things, you realize how
wrong you are, how you're always completely wrong. I'm really glad to have you on the show today because I really wanted to know more about, to learn about, product validation and product discovery and I know you're an expert in that. And most of all, what different roles do in this process? So yeah, I'm really happy to have you here today.
Thank you, thank you so much for having me. I always love talking to engineers who are into these topics. I always really appreciate it. I know many of you actually by now, so that's very cool. I also appreciate being called an expert, but I'm always quite nervous with that word. I would call myself an enthusiast or somebody who is passionate about it. That's as far as I would go.
You're definitely 20 or more steps ahead of me. So for me, you're an expert. It's a relative term. Right. So you help startups to move from more of a feature factory model for feature oriented to a more hot outcome driven model. Right. What, what were you doing before that? It worked with startups and scale ups. So, like series B, C even. Right.
And so, so actually quite a bit bigger, but also with very small startups, so kind of fluctuates there. And what I was doing before that. And so my first product role was in 2016. So I've been in tech since about 2010. And my first product role was 2016. And there I kind of built my own feature factory. And so this is, I think, why I kind of understand where this comes from.
And so my first part role was in B2B sales led organization. And where it can be quite difficult, I think, to operate in a product led way. I think that depends also a bit about how big your ticket values are. If it's enterprise sales, it becomes very, very difficult. I think this wasn't quite that. Right. So the ticket values were a bit lower.
But yes, I was working there. I was the head of product. And it was my first product role. And I was immediately head of product. And I was in my mid 20s. So I think quite young still. And I made many, many mistakes. So I, I got very great at managing deadlines and pushing features out and making my colleagues and sales relatively happy, keeping the leadership team happy.
I was good at that. Right. And it felt quite good for a while. And then it stopped feeling so good because I kept thinking, does this make sense? Is anyone actually using the features that we're building are any of the prospects that say they will sign if we build feature X. Did they actually sign no.
Right. So I started pushing more and more for having proper user analytics, having some visibility in who is using the product in which way, which features are being used in which aren't. And I started pushing a lot for talking to customers.
And so I think I learned about this on the job from doing it wrong, as they might say. And so I don't believe that working in a sales let way is wrong. Right. per se. But I do think it helps to check whether the things that you forecast that will happen actually end up happening.
Right. So we did a lot of estimating up front that we said, OK, we think if we build this feature, this will happen, but we completely missed in the beginning to actually check measure after the fact where these things happened. And so I'm working now with a lot of organizations, both product leds, but also sales led to try to kind of do this circle, right. So that when we measure, we can also learn and do a better job in the future.
And another thing that I exactly I did not work in an outcome driven way at all. So at some point I was doing my CV and I was thinking, what did I really achieve? Right. Like I built a lot of features. Yes, I pushed a lot of things out of the door, but did I contribute to revenue growth or like stickiness of the product that I do.
So many of these things and I had no idea. And so I really wanted, even for myself, right to feel like I contributed something that I had an impact. And so I started focusing on this topic quite a lot to see how we can do a better job at that. What led you to start working in a more like outcome oriented way. Like this in particular, and also this feeling right that I was being paid quite a lot, right. Product people tech people we are being paid quite a lot.
And I really had no and at this time. So first we see money was still quite cheap. And so I felt a bit nauseous a lot of the times thinking, okay, I'm sitting here getting all of this cash. And I don't know whether anyone cares about any of the things that I'm doing. Right. So it felt it felt very weird to just keep turning out features and not knowing if they're the right features.
And so that's how I got more and more into user analytics to at least understand and be able to measure. And who is who is using it and how. But then I was thinking this was still very reactive. Right. And I was still very much taking a request doing it and then measuring the results. But it wasn't the other way around that I had a clear purpose in mind saying, okay, this is the kind of impact that I want to achieve.
And this is where I want to go and going specifically there was still not doing that. And so that took me a next step. Right. And this is also very much related to leadership. And because you need to know where you're going. Right. There need to be focused goals. There needs to be a focused company strategy in order for you to be able to create a focused product strategy.
And I worked for many startups and scale ups where the strategy was very fuzzy, very generic. Like we're going to be the number one XYZ in the market. Right. This doesn't mean anything. Right. This doesn't give you any guidance. And so I started thinking a lot about good goal setting. So that really everybody has one place to run toward. And I also feel this a lot.
When it comes to silos. Right. I think even the smallest organizations start getting silos. And I've seen this from really organizations as smallest 30 people. And I've also worked at organizations as big as like 1,500 people where you have this problem really intensely. But even 30 people who start getting silos. And I truly believe that co creation and buy in into a common goal that is not fluffy, but actually mean something can really help us break those silos.
And so I find it's just really important right. I've seen organizations really flourish when they managed to get this right and I've seen organizations completely perish and die. And if they ignore these things. Yeah. Yeah. I completely agree with that. I've been there as an engineer and it was frustrating because I wanted to work in a different way. Maybe the way you work.
And but he was very frustrating because yeah, if it's not enough company culture, you can do much in that sense as an individual contributor at least. So you you got this alignment as a standpoint in your life in professional life. What was the first the first exact step you took to to move towards this new way of thinking?
So for me, I had this itch in the back of my mind for a long time saying like it should be possible to do a better job. And I also really struggled to get there because I was maybe not in the ideal environment. Right. I was not senior enough to understand myself what I need to push to work and the environment around me was not super conducive to helping me get there.
So I had an itch, but I didn't quite know how to scratch it. So at some point I got really lucky and I worked for a really nice company, a very smart leader who kind of showed me the ropes a little bit, right. And kind of explained how you do these things. And which gave me a lot of hope and you have to see it done right once right not perfectly, but but somehow better. And then you know a little bit more how you can bring that into the next organization.
And for me at some point when you start working in this kind of way, right when you start doing some discovery, right when you start talking to customers when you start measuring whether the things that you think that will happen, the things that you pretty will happen will actually happen when you start measuring that.
When you start running lightweight tests, right, like when you start doing prototypes and usability test, then after some time you're like, how could I ever, how did I ever not do this right like how did I just turn out features and throw them into the wild and just go like, I guess this is fine, right, because when you do these things, you realize how wrong you are like how you're always completely wrong, right.
And so that helped me of course, like it's a it's a it's a virtuous cycle, right, so this enlightenment kind of grows. And and now I have this great luck sort of so at some point I decided to become a solo printer and for the reason that I wanted to get very, very good at this, right.
So I wanted to get very good at helping teams move to these more outcome driven ways of working and whereas I don't mean that every single time when you have an idea you need to go down the experimentation rabbit hole right there's a time in a place for everything, but still I see most organizations could really do a lot more of it or could do it in a much more structured way could really benefit from doing a better job at this.
And I figured I want to do this a hundred times over for different organizations, so I get really, really great at it this specific part I don't want to be just okay we need a product person I'm a human I can fit into a product shaped hole. I want to come in with a specific purpose so people trust me to do this so I can get really good at it. So I've been doing that for two years now and it's been really great right so that's also helped me a lot with this enlightenment, as you call it.
Yeah, so much good stuff here. So you said you were lucky to lucky to work for a company that kind of encouraged this mindset to adopt this mindset and I remember you were writing on link it in one of your posts that the best leaders are the leaders in that are in details, which doesn't mean micromanaging. So I like to yeah if you could explain that like what does it mean exactly.
So this is also my personal experience right there's like a lot of talking about being in the details I think Brian Chesky the CEO of Airbnb I think kind of popularize the term or this as far as I know he is a great example of someone who's in the details quite a lot.
So I worked with a lot of different founders at startups and scale ups and I've seen a lot of different personality types and it's just something that I would I find very difficult is when an early states founder, especially early stage is already giving away most of the stuff that I think belongs with the founder right I've seen founders go.
Okay, here you do marketing you can figure out the goes to market strategy in the target audience here marketing here you go and just kind of toss things over the fence and like I'm busy getting VC funding. I'm out on the road and doing road shows and and and okay your products you do the products vision and a strategy okay okay and you do so like really like just kind of tossing things over the fence and and I don't vibe with that at all.
I truly believe that as a founder and all of this is your problem right like you you should be deep in the details about things like your go to market strategy your distribution your company strategy your product vision like this is integral part of what you're doing you should be deep in determining your number one ICP segmenting understanding personas this is part of your bread and butter you can't
hand that over and go like okay this is taking care of right and so I I just I don't vibe well with that super high level character traits and I've personally worked had very pleasant work experiences with people who would of course empower me and and and give me the autonomy to do these things but are absolutely engaged and a part of it as well and because they care because they understand that this is fundamental to their business and so I yeah it's just my personal
experience I've I'm much more appreciate working with these types of leaders and they can this kind of bring us to to hiring or the right people right because I imagine these leaders they need to hire people that really want to work like that maybe I mean probably there are there are also
product managers out there that they they have been always working with with a feature factory mindset and they find it difficult to move to a different mindset with the outcome driven so if those people are hired and then they get to they go to ask to work in this more enlightened way let's say
yeah it gets tough right and so you were writing about this as well on LinkedIn I remember there was a post about hiring so what's your opinion about that so how hiring can foster a culture of experimentation and the right
hiring let's say yeah I think hiring is almost is everything it's just because I so I coach and a lot of heads of products and and I coach also senior PM so mainly heads of product VPs of products and who are trying to do this with their teams right and usually the people I coach they find me on LinkedIn so they're already on board with this way of thinking I don't need to convince them at all right they they absolutely believe in this but they struggle to get their teams
to adopt this mindset as you say and because their teams are just not used to it and their teams are like 10 steps behind like behind because maybe like like I was I think in 2016 when I first started I was having a fantastic time just doing a great job meeting my deadlines and and like hanging out with my colleagues and sales and we were best buddies and it was great right I wasn't there yet
financially at the point of thinking I think what I'm doing is not right I think you need to do something different right this was a whole process for me that took me years to really get to where I am today and so I think we often come in with our mindset we're already over here and it sounds so so like I'm over here they're over there right you're just somewhere in your mind and you think okay I'm just gonna grab these people
and bring them to where I am but you can't because their they don't they don't even understand their not even at the point yet were they still going to even with point yet where they think that this other way of working is that there's any
issue with it, right? And so if you then do that, this takes a lot of time. But then there's like a huge leap between understanding, okay, I should I think I should work in an outcome driven, experimentative way, and I should have maybe growth mindset to actually understanding what what that means, right?
What you should now do because you're very comfortable with the job that you've been doing, you've been really great at sharpening your gira tickets and and stakeholder communication and doing timelines and GAN charts, you got you sharpened that toolbox. Now, but somebody says, okay, here try something new and says, okay, today we're going to do impact mapping. And your outcome is you're going to increase the free to paid ratio by 10% by the end of next quarter. Here
you go, right? And of course, a lot of people are stuck with that and immediately lose hope because they have no idea how to do that and how should they know, right? They've never worked in this way before. So you give them kind of an impossible task and and then you get frustrated that they're not living up to it. And so this is something that I see quite a lot. And I think there's two
a couple of ways out of it, right? I think there is a lot of space for education and training and and setting learning goals and taking people by the hands and giving them the right tools to grow into this. But it does help that they have the right mindset to begin with, right? It's very hard to do this with people who don't want to learn these tools. Like if you're working with people who work actually perfectly happy working the other way, it's going to
be really hard to teach them this tool. So I think the the desire needs to be there and it really helps if there's a few people around who do know how to do it, right? Who have done it in the past. And so they can kind of like a lighthouse that you have a bit of a mix. And so there I think hiring is everything, right? Like you don't need the most and the most experience people. But maybe some people who do have that experience and at least the desire to
to grow in this way. I imagine that as you started working more as with this Outcome Driven mindset, you must have had a lot of uncomfortable discussions and conversations with people working with you. Imagine. Yes, and it goes both ways, right? Because it's kind of a fraught concept because it's always like you're either stakeholder driven or outcome driven. You can be driven by one of these two things, right? Primarily, you can be primarily driven by both. And so
you kind of have to make a choice. But on the other hand, in in products, sometimes it makes sense to just, you know, do what's at stake. Maybe there's like a commitment made or there's a big cross departmental project running and you just something just needs to get shipped by this time frame. So sometimes that is the right way of doing it, right? Or sometimes something is just a slam dunk. It's absolutely sure, right? Like if we're going to do this, it's
going to work like because all the competitors have it. There's enough evidence, right? So we get into this weird, dogmatic debate. And I get stuck in this a lot as a proponent, a proponent of Outcome Driven ways of working of like, oh, you should always experiment until the cows come home or whatever expression you want to use there. And this is not the case, right? There's a time and a place for everything. And it's not
like one way is always wrong. The other way is always right. And but in many cases, when there's a lot of insecurity, and it makes sense to experiment. And it makes sense. And I think in general, it makes sense to align on the goal, which we are going towards, because I've seen a lot of organizations jump from one idea to another, from one tactic to another, right? Trying to copy the tactics of their competitors, which is extremely tempting to do. But not understanding,
okay, what are actually our goals? What are actually our strengths? What is actually our vision? Where do we want to go? And this, I've, it's just I've personally lived this too many times, right? That we just burn a business down by jumping from tactic to tactic without having clarity on goals. So that's why I believe in this deeply. And luckily, I'm having an easier time with this now, because the clients who find me kind of believe in the same
stuff. And it's it's not super easy, but it's definitely easier. And I don't land in organizations where nobody cares about this at all. Right. So if you can summarize the lessons from what you just said, few we experiment all the time, it depends. Sometimes we can listen to stakeholders, and that's fine, because you know, good answer, maybe it's not necessary to experiment, but sometimes you don't have clarity, so it's better to do
it and you move forward it. Yeah. So one thing that I hear, I read a lot on social media, but also talking with other engineers is about, yeah, the relationship between the product managers and engineering. That's a very, very hot topic. So what do you think makes a good partnership between engineering and some product managers? Yeah. So for me, I'm a big fan of context. And so when I started in product, I was very insecure. I'm still kind of
insecure, but I was very, very insecure. And and I felt the need to appear very secure. Right. So I always felt like I should have a clear answer to absolutely everything. And even if I hadn't researched it, so I would go into a backlog refinement. I think backlog refinement is always a nice moment where you see a relationship to between products and engineering.
That's respective as well, but our refinement is really nice. And and of course, I would explain what we're going to do and why we're going to do it and what's important. And then I'd outline my tickets. And of course, a lot of engineers would have a lot of questions. And that maybe I didn't have really the best answer to, right? I hadn't researched them. And but I felt back then that I should not show weakness or insecurity. So you just give an answer like, yeah, we should
do it like that. I think we should do it like that on the spot. And and I hadn't done much experimentation or any discovery, right? It was just like stakeholder came in with a request. I translated it into a nice ticket, discussed it with the stakeholder, but the stakeholder never fed it back to the customer. So this is very unsatisfying. And now when I come with something that's well researched either because the stakeholder requested
really clear. And it's just like very short that if we implement this, it will work, right? Or if I have like had multiple customer interviews, I've shadowed some customers. Maybe there's some results from usability test. And this relationship with engineers in my like for the companies I've worked at becomes much, much better. And because they will ask me questions. And I can give them all of this, this way wider scope of context. I can explain much better why we are doing this.
Why this makes sense? Why we're going in this direction? When they ask a question, I say, well, actually, I thought about that. I think we're going to go in this direction because we saw these and these results. We might be wrong, though, then we might need to adjust. So consider that when you're building it, right? So because I feel like the homework is done much better, I don't have to hide gaps, right? So I can paint a much clearer picture of where we're going
and why we're going there and why it makes sense to do this thing. But I can also be much more honest about the things that I think might be true, but only 15 out of 20 people said this, right? So I can take it with a grain of salt. I can be much more open about this stuff. And I feel like for me, that's really helped in the relationship with engineers. It also means that I spend much less time writing the perfect tickets, right, with all the requirements spelled out, but I spend
much more time bringing them into the context. So they don't need all that detail in the ticket, because they have the bigger picture much more. And luckily, I found that most engineers that I work with very much appreciate this and totally enjoy this. So I feel like it's really helped the way we work together. We can also be much more honest with each other about the things we don't know, kind of embrace uncertainty, as they say it. Right. So after these experiences you had,
it's been always this easy? No, of course not. No, it depends, right? And there's always, this is kind of what comes back to come back to a lot of things. And I think the leadership team needs to be on board, or at least a large chunk of it. And it becomes very difficult when there's one lone warrior trying to do this on their own. And once you have that, I like, for me, the CEO
is usually very important, right? I'd like to have the CEO on board with this line of thinking, because I need somebody usually top down to help kind of push these initiatives of goal setting, alignment on an ICP, alignments, right? Like so that we can run in the same direction. This is for me, the foundation of everything. Because if we're going to work in an outcome driven
way, we need to align on which outcome that is. And you can't do that on your own. You need, and you need somebody top down usually to say, okay, now we're going to sit down and think about this and not saying it's going to be this, but at least we're going to kickstart this process and we're going to drive this process forward. And so with that's been lacking, it's been very, very difficult, virtually impossible. And I have been there, right? I've also been brought in by an
organization where they said, we just need a product person. And then I convinced them that they need to do these processes. And they were like, oh, yeah, okay, yeah, I guess that sounds cool. Yeah, why don't you come and do that? But it didn't come from the CEO. It didn't come from the leadership team. And then when I was in, I very much felt it because they were never going to push it over
the hill, right? They were never going to back me enough to make this a reality, to actually have these sessions and to actually come to something fruitful and actually steer our daily operations into this direction. And so I kind of learned from that that I really look for a strong driver within the company, CEO, sea level, who comes to me because they already convinced themselves of the need to do this. And I shouldn't try to persuade them. And so that's from the leadership
level. And the other side, the flip side is of course the people who are doing the work. The employees and it helps there as well that at least a large chunk of it of them is motivated to learn or wants to do this kind of stuff. And all I need is at least motivation, right? Or desire to change this kind of stuff. They don't need to be crazy experienced. And sometimes when it's a relatively immature product organization or tech organization, you could do really small
things and it has a huge impact already, right? You could do really small process changes. And it makes a really big difference really quickly. Also, you see kind of light bulbs go on. And that's very fun. But if that motivation isn't there, it's really hard to do. Right. So in the situations where you know, you had this of people that were not easily convinced and you know, maybe impossible, let's say, is there something that didn't make you give up to push your goal of
you know, working in this way? Yeah. For me, it's all about the people, right? I think it is all about people in the end, right? It's all about the humans you kind of impact, whether it's customers or the humans you work with. So it doesn't have to be everyone who's totally excited. But if I see just a couple of people who are for who it clicks, I think that's already quite a great impact that I can have, right? I would I really I strive to have an
impact on business metrics and product metrics. I really want to come in and help this organization say, okay, we have a goal. We want to grow to one million AR by the end of the next year. I really want to help them do that, right? Like really hard metrics. But there are cases where the setup is wrong, right? Leadership team says, yeah, I want to grow to one million ARR, but doesn't want to do any of the other alignment steps that is necessary to do this.
It's going to be really hard, right? Then I'm kind of cut off at the knees. So then the impact becomes more about the people that I can maybe help for whom it doesn't make click at some point. Yeah. Yeah. It's a bit it's a bit the same like the agile transformations, right? So in bigger organizations that they want to bring the agile mindset, and they they have maybe just a small team working agile, maybe with a framework or I don't know, but the rest of the
organization is still working the same way. So it's impossible to do it properly. So, you know, an interesting thing that was thinking about even before our interview is, so with these engineers, but also the other roles that find it difficult to adopt this mindset, you know, changing people is difficult, if not impossible. I mean, we know that even from our
daily lives, for other topics, it's very difficult to do that. But I don't know, for example, if I think about marketing, so one of the goals of marketing is bringing awareness about some problems, some pains that maybe a person has, so then you can sell a product. If we take this this to, I don't know, an engineer, what would be, what do you think would be like a pain point,
they wouldn't need to have in order to change their mindset. So we'll kind of have more awareness, instead of just telling them, yeah, you need to work like this, not like this like a dictator, but just saying, okay, these are the benefits, it's gonna be good for the company, for the product, but maybe that's not gonna be very convincing, something that can touch them on a personal level, let's say. Yeah, I think it's a lot in like guiding them through the experience one time, two times,
so that they just feel the difference, right? So me, like I often work in product trios, which is a concept from Teresa Torres, and her book continues Discovery Heavids, where there is an engineer and a designer, and often my trios are a bit bigger, because I like to add other people
in, so in my last product trio, I had product marketing in as well, I like to get a data person in there as well, because I'm a big fan of cross departments and mental code, the collaboration, and also inviting people into the process, doesn't mean they have to join, but that they are able to
join into the process. What I often see is that in the beginning, so I book a lot of interviews, for example, and we do a lot of usability tests, so we do a lot of experiments, and I always invite also the engineer to the interviews, and they often in the first month don't join. Because it's also really hard, because they may become from a mindset where interviews are a waste of time, or I mean meetings are a waste of time, and they should be coding,
because they were hired to code. So it's very hard also for them to all of a sudden say, okay,
I'll just accept this one, accept this one, blah, blah, blah, blah, and I totally get that. But then when you get further in the process, and you have these first, for example, refinement sessions, where you can point at evidence, then like, for example, I always have these big mirror boards, where everything is logged, et cetera, and I always see after we do the first refinement, blah, blah, blah, all kinds of engineers jumping in there, because they're like, what is this?
What did she do? So you kind of just start doing it, and I don't grab them by the collar and say, you must sit in this interview, I'll just do it for the first round and show them the results. And then you see interest comes, right? And then the next round, right, people, there's like a couple of people who want to join the interviews. And you also can tell that there are people who have been kind of waiting for this, but they didn't know they were waiting for it, right? They
didn't know that this way of working also exists. But they're like, wow, this was great. I got from my last client, I got the feedback from a lot of engineers, and I really liked it. It's like, it was a breath of fresh air to have you in there. It was like, yeah, and I found that really beautiful and really nice. And I saw there also the beginning nobody came, and in the end a lot
of people came. So because they see the outcomes of it, right? So you can't have a dogmatic debate as in you should do this because it's better, but you can show them the real results. And that's I think the best way to convince people. Yeah, in my personal experience, I can often see that maybe the need to work more on up with the product mindset is hidden in the frustration that a lot of the engineers have that they don't see their impact in the job they're
doing. So they are handled some tasks to do. Maybe they choose some tasks from the backlog. They develop them, and then they go in production and that's it. You just you don't know what's going to happen. Maybe after one month, someone is going to tell you there is a bug there and they fix it. Yeah. So a lot of developers find it very frustrating myself. Of course. I'm
going to the first one. So I think, but they don't know, okay, what can I do about that? Like, they don't feel like empowered or maybe they don't know at all what can be what can happen in that sense. So yeah, it's hopefully what people will become, whatever it is. Yeah. Because this is an organizational thing, right? I see so many companies who do this, they spend, they might be good enough to spend a fair chunk of time in what happens before launching a feature.
Like the some organizations, the most immature organizations, they just, you know, they get a request in, they translate it into a ticket and they push it out. And then that's it. And then there are other organizations who get a request in and then they do some research, right? Still maybe run an e-test or they do a prototype and rub around and they get result in and they say, okay, based on our results, we think this is a good idea. Push the feature out so then at least
they can tell developers with some evidence and some proof points. But then still, they don't measure after the fact whether any of the things they predicted would happen actually happened. And and what I get often is I do, right? I always then go in because I'm actually checking the data constantly in production, like what is actually happening. And I'm saying, hey, we predicted here that if we change this, we would get a 5% uplift between here and here.
But now we're year on and actually we are decreasing there. We don't have an uplift with the opposite. And then I've always get back excuses. I always get back, yeah, but it's a seasonality or it's you know, it's out of our control, it's economic circumstances and they're sure it's out of your control probably. But still you should try to understand it, right? Because otherwise the next time
you will predict something, you will again be wrong. And I think what you're saying is that developers don't get feedback about what happens in reality is because organizations don't check it at all because there might be worried teams sometimes don't check it on purpose because they'll be like, okay, whatever I found out, I can't learn from it anyway because what happens in the real world is out of my control. I only control what is in this nice vacuum of a test environment.
But this is not how you can grow a business. It doesn't happen in that test environment. It happens in the real world. So you have to look at it. And so I spend a lot of time looking at that. And then also when you get used to that, you can give that feedback to developers. But I think a lot of product teams don't do that at all. And then from leadership teams, you will get some feedback that you can't use because from the leadership team, you will only get revenue spikes or revenue
went down. Like you will only get these insights on lagging indicators that you can't really use for actionable insights, right? It should be the product team, I think, that points you towards what's changing in these product metrics, which are the ones that you as an engineer try to move. But that's just not happening. That loop is not being closed nicely in most organizations.
Yeah. And I also wonder how my non-engineers' colleagues do related to this. So I was reading recently, I read this new word because you know about code monkeys, which is like, you know, what we just said. But there is also like the pixel monkey. It's related to designers. So that's a good thing. So I think probably there is the same feeling of frustration also for other roles. So maybe for UX designers, for marketing, people. So what's happening in with other roles in your
experience? So I think in the end, it doesn't matter the role, right? It's just a kind of person, I think. And there are a lot of people who are just who do think bigger picture, right? Also sales marketing, like in every role, there are a lot of people. I think they're sitting there thinking, does any of this make sense? Like, why are we doing this? What is the point of this?
I think it might be even more painful or equally painful if you are sales. I know a lot of sales agents who it's their job to try to convince people to buy a product and they don't really believe it's better than the competition, right? This is a very common thing. And that's extremely painful because you're sitting there trying to convince people and you're getting arguments and you actually don't believe that your product is the right choice for this person.
So I think it has to do with a type of person who says, okay, I need to at least, I need to cross these boundaries, right? I need to understand what the company as a whole is doing. We need to collaborate better. We need to break the silos. We really do. And we need to understand what we are running towards, right? Because I think a lot of dissatisfaction really comes, whether it's in sales marketing, engineering, product or design doesn't matter. It really comes
from lack of a plan, right? We don't have a common North Star or we don't have anything that we're all pulling towards and running towards. And there's no clear competitive differentiator, for example, this is like a thing that I work with companies on the lot is to understand why do we even exist at all, right? What is our reason to be in the market? Why are we 10x better or cheaper? Why, what problem are we solving? And often that foundation is missing, right? Because we just got kind
of caught up in a hamster wheel at some point. We had this idea at some point, but then it didn't really work out. And we started playing catch up with all the competitors. And now we just kind of have this product that kind of does a lot of things, but it's not really great at anything in particular. And we're not really sure who it's for. And everybody feels that, right? Or at least the people who are thinking critically and there are those people are in every department.
So I don't think it's a role-specific thing. It's just a critical thinking, bigger picture, thinking mindset thing. Right. Okay, as a closing thought, I'd like to ask you, if you could share with the listeners, maybe some, but one, two or three, up to you, practical tips of, like if you were coaching like a leader in an organization to do product discovery in a more collaborative way and to involve everyone in the process, what would you suggest to do practically?
So when it's about process covering, so the first step, so I do this a lot, right? And there's a couple of steps. So probably discovery, you can say, okay, just start talking to customers, right? Just start looking interviews. Yes, but because you first need to decide which who are you talking to. And also what is the scope of your exploration, right? Like what are you discovering? And so that is a lot of alignment work for. So I usually start also with the leadership
team. This is why it's very hard to start this from the ground up when you don't have those things in place, right? Because you need to understand first, what goals you're trying to achieve and what are you trying to learn about? So for example, when I do discovery, I can have an either a very narrow scope. So I can ask people about the current product and try to find their pain points in the current product, which works if you're quite solid on your core value on your differentiator and
all that stuff. Then that narrow scope is good. But if you're actually considering to open it all up, right? And you don't really know your competitive differentiator, you should have a very, you, it's probably better to have a much wider interview scope where you're just trying to uncover people's general jobs to be done and the friction points the experience or the unmet needs the experience. So it's a totally different conversation you're having. So I think you need to understand
a line on, okay, what are we trying to really learn? Right? And this is leadership alignment or like larger skill alignment. And then you need to align on who are we learning from? Who is our ICP or which persona are we learning from? And because if you don't do this, you will be collecting a lot of noise, right? So I think there's a lot of advice going on, just start booking interviews, start talking to people. And I understand that mindset, right? Because it is also just get into
the habit of things. But you should talk about the right stuff with the right people, ideally. You're going to, you're not going to get those results and you're going to actually maybe make the wrong decisions because you collect a lot of noise and no signal at all. And so you're going to draw the wrong conclusions. And so I think I would really start there understanding who you are building for. Who is your ICP? Which persona like, who is it for? And secondly, what scope of
conversation are you having? Right? What are you trying to improve? Yeah, I think those are the biggest start. And then of course one big thing, please don't ask people, hey, I have this idea, do you think it's a good idea? Don't do that. Because you're going to say, yes, it's a good idea. So you have to let them talk a lot like you let me talk a lot today. Thank you. But you shouldn't be speaking a lot, right? You should prompt them to speak and then prod into what is interesting.
But yeah, don't pitch, never pitch. Nice. So else, what's next for you in your professional life? What's what's happening? And so I'm currently working on a project that is very, very interesting that I enjoy very, very much with the company called Wave. And so that's what I'm going to be working on in the next couple of months. And then after that, my professional life will be on hold for a bit because I will deliver a child. Congratulations. Thanks. So I have a maternity leave plant from
August onwards. And but then I will probably, I'm estimating to be back in the professional world in about March. And hopefully I'll get to continue the kind of work that I've been doing. And because I feel like I'm just getting steam. And I'm very much enjoying it because for me, thanks to the LinkedIn content, I've been finding clients or clients have been finding me that are just a very good fit. Right? So we share the same mindset. So it's just incredibly fun to be able.
I feel very lucky that I get to do this work. And because I coach a lot of people who want to do this kind of work, but are kind of still a bit stuck or having a harder time, who could get unstuck, but it's quite a struggle. And so I feel like I'm very lucky with where I am. So I hope I can keep doing this. Yeah. Good luck with everything. Thank you. Thank you. Where can listeners ask you questions, find you online? What's your favorite place for that?
So I'm on LinkedIn. And so yeah, maybe you can post a link underneath it, but everybody is happy. Please feel free to connect to me. And I also write a substack. So my substack is my name.substack.com. We can also post it there, but basically else from the back, as you see it written in that screen.substack.com. So there I publish and quite a lot. Perfect. Cool. So thank you very much, Helz for being with me today on this show. And yeah, talk soon. Thank you so much for having me. Bye.