Growth Leap
Welcome to Growth Leap, a Stun and Awe podcast that looks into how business builders design and grow their companies for performance and impact.
Growth Leap
How to Prioritize, Experiment, and Build Products That Matter with David Pereira and Büşra Coşkuner
David Pereira is the CEO of Omoqo, and Büşra Coşkuner is a seasoned product coach, both experts in helping teams build products that actually matter. In this edition of Growth Talks, David and Büşra break down the biggest challenges in product management, from prioritization and experimentation to balancing discovery with execution.
We dove into how to avoid wasting time on ideas that won’t work, test assumptions quickly, and make ruthless prioritization a habit. David and Büşra also shared insights on working with business pressures while maintaining a strong product vision and execution strategy.
David discussed the importance of setting outcome-based goals instead of getting caught up in feature-building, while Büşra outlined a framework for effective assumption testing that ensures teams learn fast. We also covered how to prevent roadmaps from becoming feature factories and the common mistakes teams make when trying to scale their product development.
We covered:
✅ Prioritization strategies: How to decide what’s worth building (and what’s not)
✅ Experimentation 101: How to validate assumptions before committing resources
✅ Balancing discovery vs. delivery: How to manage roadmaps without overloading teams
✅ Ruthless focus: How saying no leads to better, faster decisions
✅ Real-world case studies: Examples of what worked—and what failed—in product teams
✅ Managing business pressure: How to balance leadership expectations with product strategy
Whether you’re a product manager, startup founder, or team leader trying to build high-impact products without drowning in unnecessary work, this episode is full of actionable strategies to help you focus, learn fast, and execute effectively.
Follow David & Büşra on LinkedIn
🔹 David Pereira
🔹 Büşra Coşkuner
Where to Find Michel:
📰 Newsletter: Stun and Awe
🔗 LinkedIn: ichel Gagnon
🐦 X (Twitter): @michelgagnon
📢 Enjoyed the episode? Subscribe, leave a review, and share it with your team!
- Do you have a question you'd like me to answer on the podcast or feedback to share? Leave me a message here.
- You'll find all the show notes, transcripts, and past guests at stunandawe.com
- Up your growth game with our hands-on Growth Marketing Course
- For inquiries about sponsoring the podcast, email marketing@stunandawe.com.
- Support the show on Patreon
Follow us:
POD045 - Growth Talks - David Pereira and Busra Coskuner
[00:00:00] David Pereira: So this thing of copying the competition, you need to be very careful. Because then you may create something just for the sake of creating. Maybe people like it, but you don't know the problem you solved.
Welcome to Growth LeapWelcome to Grow Talks
[00:00:13] Michel: Hi everyone and welcome to Growth Leap. I'm your host, Michel Gagnon. We talked to pretty awesome business builders who are designing disruptive and meaningful companies.
[00:00:22] Michel G: Hi everyone and welcome to the fourth edition of Grow Talks. Thank you so much for joining us today. I will speak slowly to let the time to, you know, the other participants and attendees to join us.
Previous Editions Recap
[00:00:35] Michel G: Uh, we've, it's the fourth edition, which means we have three previous ones.
If you're interested in watching the replays, they're available. On our website at stun and all. com in the resource section, just to give you a quick idea. We had, uh, the first edition, which was focused on growth with Alexi Habensky and, uh, Avid Cal, a, um, author also and founder of the bootstrap founder.
We had an edition on scaling your startup international internationally with notion and sharpest. And the last one last year was. About buying or selling your startup with, uh, Andrew Gazdicki, CEO of, uh, acquired. com and Killskill Rod from Scaling Venture. So it's a great format, as I was telling my guest earlier before we, uh, went live.
It's a great format because it's fun. It's friendly. It's also extremely efficient because, you know, we can dig deeper and build on each other's experience. So I'm Michel Gagnon, I will be your host. I'm an entrepreneur, advisor.
Today's Session Overview
[00:01:37] Michel G: Father, uh, former tech CEO and, uh, someone who's quite passionate and creative, passionate about, uh, helping teams and leaders, uh, build, uh, products and things that matter before we dive in a quick note, we'll run, uh, on how we'll run today's session.
So we got an hour. Uh, together, which I think is plenty of time for us to cover quite a lot of ground instead of saving your questions for the end. I encourage you to drop them in the Q and a tab. So if you look at the bottom of your screen, I think on the right hand side, there's a Q and a tab. Make sure you put them there to help me make sure we centralize things.
And I will try to. We've them in into our conversation. So we get as much out of our panelists as possible. So you're in for a treat today. We've got two incredibly experienced and insightful speakers with us, David Pereira and Bishra Joshkunar, both of whom bring, uh, years of experience, hands on experience in product leadership strategy and building products that drive real impact.
So this is your chance to pick their brains. Don't hold back. And with that, let's jump in instead of me listing out all of their accomplishments, which would probably take the full hour, I will let them introduce themselves.
Meet the Speakers: David Pereira
[00:02:55] Michel G: And I suggest we start with, uh, David, why don't you start, you know, tell us a bit about yourself and, um, yeah, go ahead.
[00:03:03] David Pereira: So I'm David Pereira, I come from Brazil, I've been working with digital products for about 17 years now, from soft engineer to CEO, different parts. In short, I'm a very curious person and relentless. I like challenging how we do things many times. I like simplifying what gets unnecessarily complicated. So apart from being the CEO of Omoco, I also coach teams my free time because I love doing that.
[00:03:33] Michel G: Great. And you also have a Relatively new book that came out on trapping teams
[00:03:40] David Pereira: just behind me.
[00:03:42] Michel G: Great. Yeah. I've read it.
[00:03:45] Busra Coskuner: I want to mention.
[00:03:49] Michel G: Great. All right.
Meet the Speakers: Bishra Joshkunar
[00:03:50] Michel G: Well, welcome David, uh, Bishra your turn.
[00:03:53] Busra Coskuner: Yeah. Hi. So I've been a product management for. I don't know. I stopped counting after 13, but it must be something like 15, 16, something like that. I, I don't, I don't know anymore. Um, uh, always been hands on, like even in the time that I'm a product coach now, my mantra is always to make abstract product theory, tangible and practical.
So what I do now for five years now. More or less, um, is that I help companies to turn into product organizations. I help, uh, product leaders, um, as a sparring partner for their strategies and how to set up their teams, et cetera. Um, and I'm a one on one coach for, um, that's unusual for a senior and lead PMs, um, to help them, you know, I call them, they have, I, I, I keep saying they have a schizophrenic.
role with being in IC and at the same time having leadership responsibilities and I help them navigate this schizophrenic, um, role, um, with, um, ease or to make it easier for them. Yeah.
[00:05:01] Michel G: Great. It's funny. I don't have
[00:05:03] Busra Coskuner: a book. I'm not planning to write a book. Um, I do give talks and, and, uh, speak at conferences, meetups, et cetera, um, give back to the community.
Um, Yeah, and run workshops.
[00:05:20] Michel G: Welcome. Thanks and welcome. Uh, thanks for your time. Uh, I find it interesting that you've talked about, you know, schizophrenic people because, um, I used to be,
[00:05:30] Busra Coskuner: uh,
[00:05:32] Michel G: roles. Yeah, but I, you know, yeah, but I, I would say the, the, the line is can be fine sometimes. And I've, this is how I felt, uh, myself when I was a tech CEO.
Where, you know, you face a lot of competing priorities and, and, and goals and requests from, from everybody else.
Challenges in Product Development
[00:05:50] Michel G: So I'd like to start with kind of one of the biggest challenges and I think product development or in building a business, uh, figuring out which ideas are worth pursuing. And I know we'll be, uh, jumping, you know, on and off on different teams.
They're closely intertwined, but I think today. Or in general, you know, there's a lot of possibilities when it's time to build something. Today with AI, um, it's even easier to build stuff. And I think it'll get easier, you know, in the next 12 to 18 months, which I think is both a blessing and a curse because it gets very easy to start building stuff that nobody wants.
So my first question is, how do you zero in? On the ideas that will have the most impact while, you know, staying within the confines of your resources and priorities. Uh, David, do you want to give it a stab?
[00:06:46] David Pereira: Sure.
Learning and Experimentation
[00:06:48] David Pereira: So, it's all about how fast we can learn. Because what I see, like, there's strong discussion on prioritization.
And one of the dangers called plural. So I see many teams saying these are our goals, these are our priorities, and then it's competing all the time. So what I see as important is Take everything as a bet. So recognize the strength of the evidence you have. Like, how do you know customers want that? How do you know you can collect value?
How do you know you can deliver? So you say, what can we learn in a day? What can we learn in a week? And then try learning. And they say, should we continue investing in that? And so on. So it's very important to get out of the office, to get the idea out and learn from reality. Because many times. The trap I see teams keep discussing and discussing and more discussions will not make the idea better.
We will not increase any chance of being more successful. It will just drain energy and there's certain fear about it. So the challenge is recognizing the reality we have and and seeing like what can you do right now to learn. About something.
[00:08:02] Michel G: And maybe if we keep diving on this, you you've mentioned, you know, try to learn as much as you you can.
Bishra, can you tell us a bit like the kind of signals that you would be or the, you know, evidence is a big loaded word. Um, so what kind of evidence or maybe the quality of the evidence that you look for usually when you start experimenting and looking for that great idea?
[00:08:28] Busra Coskuner: Um, good question because the answer will be, it depends.
So, um, here's the thing. Um, I mentioned, um, I mentioned that I'm, that I'm making abstract product theory, tangible and practical. That means when I work with teams, then I need to look into their context. To then have an idea of what those signals look like, like, for example, in B to C, a company that I'm that I'm working with is a B to B to C company that is now trying to go to B to C directly, right?
And for them that the signals towards the consumers. Are different ones than towards their business customers and towards the business customers. It can be signals, right? Uh, like, um, when your contact. Um, well, let me take one step back in general. Talk about first principles, thinking the strongest signals are purchased, right?
When somebody says, I'm going to buy it, I'm going to pay for it. That's the strongest signal for a product, a new product. So there's another dimension of, are we talking about a product versus a future? Right? So if we're talking about new products and the strongest signal is of course, somebody buys it.
Um, now in B2B, these buying cycles are so long. That waiting for a purchase can be too long, right? As David said, we need to be fast, right? We need to be learning fast. So what is the Next strongest signal. Oh, maybe it's a letter of intent. Make what is the next strongest signal? Well, when your contact who actually has no say in in a buying decision suddenly invites somebody into the meeting who is the budget holder and who is the yes or no say.
Well, that's a signal, right here. We talk about strong commitment. So if that is a very strong commitment for your contact on the other side, like when we, when we talk about B2C, now the company that's, that is trying to now go to the market directly, they have to have a buying signal because consumers are getting a consumer to buy is faster.
Now, again, it depends on the product type, right now for this company. It's again, a big buying cycle. So as soon as you understand that the, the prospect is interested in what you're offering, that is already a strong signal, at least in the terms of problem solution fit. Now, if it's also product market fit, that is still to be defined, but then again, it depends, right?
So what we are, what, what I, what I like to say is. So I'm, I'm, I'm about to, um, um, launch my blog post about it. So I, I call it the gating system of experimentation. So we, we explore first, then we look for light signals to understand if we're going the right direction and then we look for strong signals.
And if you're really pro, you start with a strong signals, right. And, or strong commitments. And when you find those strong commitments. This is the strongest signals that you can have not easy in every situation. Therefore, it depends, but first principles thinking, think in your situation, what a strong commitment look like, looks like in a reasonable amount of time, because as David said, I cannot wait months and months and months for a strong commitment.
[00:11:51] Michel G: I know I'm, um, destroying the structure that I had set up initially, but, um, it doesn't really matter. So if we, um, I'm. There are two key themes that I want to cover. I want to make sure we cover that. So if we, um, uh, if we don't get there, make sure to bring me back.
Designing Effective Experiments
[00:12:08] Michel G: One of them is, and that's what I want to tackle now, is designing experiments, um, so that you can learn, right?
So I'd like to tackle this. And later, one of the things, and this is a bit selfish from me, because one of the challenges I faced was to Manage the roadmap slash the portfolio of activities. Let's say that are happening in product and engineering, right? So people talk about delivery versus discovery versus validation.
How do you, you know, manage that portfolio of activity? So let's start with experimentations. A lot of people talk about experiments. Personally, I've experienced, I've been in a lot of meetings where people say, okay, let's build an MVP. That, that was the experiment. Um, one of the, the terms that I've, One of the terms that I've discovered is the minimum viable test.
And, um, I like it because it forces your mind to think about, uh, minimum. Right? Because tests can be big. So I'd like you to, uh, walk me through a little bit. Um, through your process, and maybe we can start with you, David, David, on this. How do you, you know, when you tell your team, okay, this is an idea we should explore, how do you design that experiment so that, you know, maybe there's a beginning and an end?
Um, how long is that experiment? Um, do you have a lot of, uh, Um, how should you say, not, not safeguards, but you have a lot of, uh, prescriptions, let's say around how you define and run that experiment.
[00:13:43] David Pereira: So it depends on the complexity of creating something. So I would say the more complex it is, the more you should invest into.
But let's take my book as an example. Like, I didn't plan to write a book either, but some people started asking me after presentation, What about a book? What about a book? So that was a sign. But then I said, like, how do I get a strong commitment? And the first thing I did, I said, I'm gonna post that I'm writing a book and see how people are gonna react to that.
And I will post also a form that they will give their email and say, I want to get the book once it's live. So let's see how many people get there. And I said, if I get at least 200 people in the next two days, there's a sign, then I can explore further. So I didn't have the book. I had only a title for that.
And then in one day after posting on LinkedIn, I had 500 people who said, I want to know more about it. So after that, I said, now let me understand more their pain. So I interviewed 10 people. I found some interesting aspects there. And then the next thing is like For this, I found desirability. People in my network would like to learn about X topic.
They were tired of getting many books that tell them where they should be, but now not how they get there. So I said, but can I write a book? I write blog posts. It's a very different game. Very different. So what I did, like the next experiment level was I want to still increase the commitment. So I will write a guide, which is supposed to be a chapter in my book, but I'm not going to give that for free.
I want to see if people are willing to pay for that. Are they willing to pay for something like that? So I put in my newsletter, um, a guide and I called the strategy guide and then I increased that. So I got a hundred people paying for that and in a week and then I said, aha, so there are some people willing to pay.
Then I checked how satisfied were with that. I said, will they keep paying if I put something else? So I put another guide there. So I keep evolving. So I didn't commit fully to write a book initially. I started running experiments that would hint in the direction I should write. And what I learned in the end was the stories were the most powerful.
I thought it was about the practice and so on, hands on and everything. But people wanted stories. Stories is what Resonated the most. So I did this and then I could eventually write the book, but the product is the same. How do you increase the commitment as fast as possible? So I started with email then with a commitment of mine.
I do the same with the team and say complexity. Writing a book is highly complex. It's going to take a lot of time. So I need to run several experiments to ensure I go in the right direction. and continuously doing that. With product B2B, B2C, you need to understand your scenario. Context matters a lot. And then you, you start running with experiments.
The first experiment for me, they give direction. They give signs where you could go, and then you need to find other more robust experiments. So you can learn from that.
[00:17:01] Michel G: And what about you, Bishra? Do you have, um, how should I say specific guidelines for a team to define and design experiments?
[00:17:13] Busra Coskuner: Yeah, so the guideline is start with a question that you want to get answered. What is the question that is open? What is the gap? What is it that you're trying to learn? Right? So let's think about the build, measure, learn loop, start with learn.
What do you want to learn? And then you can think about what the right experiment is to learn about that, because the experiment you're going to run. We'll give you some measures. Are these measures the right ones to tell you what you want to learn? So again, first principles thinking, right? So what what I then do is, um, I mentioned the gating system.
And what I then do is I do a quality check. Where are we? Have we actually explored enough? And then I really look at, um, uh, like with them, I look at what we have already before we start everything from scratch. Right. So maybe there is a, when loss analysis, um, from the sales team in B2B, right. Or in B2C, we have lots of data already, um, um, in our analytics system and so on and so forth.
So I, I, I look with them into what they already have and then we, we decide where we are. And then we go through these checkpoints. And then one thing can be, for example, so you ask about experiment design and minimum viable test. So, um, to mention that I never use these words when I train, um, product teams or trios on how to do discovery, how to do experimentation, how to set the right success metrics and so on and So I never use these terms because they're so loaded.
And, um, if we take the original intent of MVP, then this is actually the smallest thing that you can do, not necessarily build, the smallest thing that you can do that creates the learning that you're trying to achieve, right? The learning is the goal for, for an MVP. And if the learning is, I want to see if the concept that we have right now is good enough.
It's very small. It's tiny, but I want to see if it's good enough. That it's interesting for our, um, business partners to upgrade with this module. Then, this is the question that you're trying to get answered, right? Then your experiment design depends on your context, on your situation. This is a real example from another team that I'm coaching.
And, um, so for example, then the next step would be what's perfect versus what's pragmatic and the pragmatic way, but not the perfect way. Maybe to blend some things into one experiment and be like, okay, we have our data sheet and now we'll refer to, uh, David bland's, um, great book, testing business ideas, right?
So that's a. It's, it's my almanac of, of experiments. There's of course a lot more, but that gives you a pretty good starting point. And, um, and, um, you might say, we think we have a data sheet here, a fact sheet or a pitch, a presentation, right? Prepared. And we're going to give this to our sales colleagues and ask them and ask them, give them a script and ask them to really follow the script and see if they can sell it.
Of course, this requires cooperation and not. Enemies, right? So it needs collaboration with with with sales. Um, and then the hypothesis might be we believe that the solution that we have this small thing that we have here is enough to upgrade our existing customers. To the or actually cross sell cross sell them this module by the price tag with the price tag of X.
So now we put two experiments into one, but that's fine, right? Because we want to be pragmatic. How often do you get to call your business customers, right? So we want to be pragmatic. And then we check how many of them said yes, and how many of them said no. And then, of course, we ask our sales colleagues to.
Understand if they say no. What is the reason if price is the reason or the whole complexity behind their business or whatever that is? And if price is the reason we immediately learned that the price is not the right one. So then we have to adjust, right? So therefore, about experiment design, it always starts with the question we want to get answered and with the hypothesis or the Assumption and the hypothesis behind the thing that we have in mind,
[00:21:39] Michel G: David mentioned in the recent, uh, presentation that he gave.
I really like that quote. Um, and, you know, if there are any kids, um, On the call, make sure that you, uh, do not listen to that part, but he's, you said something like untested assumptions is the mother of all fuck ups or something like this. I love it. Can you give us some, uh, some examples like of, um. of experiments or assumptions that you wanted to test and how you kind of tackle them and maybe, you know, ended up, uh, being great or, and I know you're, you're not afraid to share, uh, the good, the bad and the ugly, but, you know, if you could give us a couple of examples or an example, that'd be a super useful.
Real-World Examples of Experimentation
[00:22:26] David Pereira: So let's give an example where not testing the assumption ended up in a very ugly scenario. So that was still in Brazil. It was an agency and we trained the sales force of big companies all over Brazil, like Adidas, Philip and so on. People who advertise in shops. So we had trainers traveling all over Brazil.
And then one day we were discussing prioritization and a business analyst said, it takes very long to create the reports because I have to consolidate the spreadsheets from. 50 different trainers and everyone has a different format and no matter what I do they do whatever they want. They change that.
Then the problem for me was, the problem apparently was clear. So yeah, they're gonna consolidate and so on the data. It's very hard to create a report. And then someone said, let's build a training platform. So everything is there and so on. It's beautiful. It's easy. We started looking at this and said, great, let's do that.
Then we started designing and then we develop and look great. So I traveled to the South of Brazil to present to 50 trainers. And as I started presenting, they had a really skeptical face. And I was presenting and someone looked at me and said, how do I use this when I'm flying? I said, what do you mean by when I'm flying?
He said, the only time I have the chance to fill out these forms is when I'm flying, because I'm, I'm all the time on the move and flying is when I have peace to do that. And that's why I use Spreadsheet. And then it's when I realized. that we completely missed the problem space. There was an assumption that I would use a web portal.
And that was Brazil 2015, I think, something like that. There were no, there was no internet in the planes and so on. And that's when I realized. All right, three months of investment straight to the trash. Of course, then we created a beautiful solution that you could upload the spreadsheet there, but just created more noise.
So we created more problem. So that's an example where not testing the assumption led to creating problems we should not have in the first place. But then I learned this hard lesson in my life. In another place, what happened was I joined a startup and then I arrived there and the CEO told me, you need to redesign our app.
So our audience. It's going to use it. And I say, how do they like the app right now? He said, they don't. They hate it. They think the app is crap and everything like that. But if you redesign it with a clean and beautiful design, it's going to be right. And I said, assuming that they want an app. And he said, of course they want.
The road is going to go mobile. Everyone needs an app. I said, let me go and test this assumption. And I visited our customers and so on. And I realized that none of them use the smartphone in no moment of their work. And I was looking, they all use big screens and so on. So the assumption was proven wrong.
Actually, I ditched the app and then we developed, in this case, a web platform. And it was quite successful. But it was important to see reality and test this assumption. And what it took to test it? Was just visiting three clients. And when I visit them, I could directly see why they were not using the app.
It was just not natural for them. So that's the thing I like understanding, like what is natural and what is rational. If it's rational, it's very hard to change behavior from people, but if it's natural, it's just integrating their day to day.
[00:26:15] Busra Coskuner: If I may, if I may add to that. So what I like to do is, um, especially the first example, David, this is so great.
This is what, what, what I refer to as, um, I call it the solution versus the solution of the solution.
Assumption Testing vs. Solution Testing
[00:26:28] Busra Coskuner: And, um, so there's a, there's a way of, of like, first you have to, um, dig into the assumptions behind the solutions and, and do the assumption testing to understand if this. The overall idea of like that solution is actually the right one.
If that is actually right. If that is actually Um, worth pursuing because the problem is worth pursuing. And then once you say, yes, it is, then you get into the solution of the solution and then you go into solution testing, right? So there's a difference between assumption testing and solution testing.
And, and that is something that I find also very, very incredibly helpful to understand. Um, and, and that is the part where you definitely need to have the, the, the engineers in the team doing that as well. Like when they come up with. Okay, so you explain us the problem is XYZ. We understood that it's an important problem to solve, but why don't we just build a CSV upload?
Yeah, cool. Let's do that. Right. Instead of instead of building a whole internal like real story, um, from my time at home 24. Um, so yeah, basically, yeah, instead of building a whole new internal tool to Do X, Y, Z. Why don't we just build a CSV upload? Oh my God, this is so easy to build. It's maybe not super convenient for our internal stakeholders to use, but that's the time that we have.
And in this time that we have, that's what we can squeeze in. That solves their problem already in some way. Mm-hmm . And it's good enough, like for now, because we have so many projects to, to work on. Right. So sometimes, sometimes it's just about that.
[00:28:12] David Pereira: Yeah. And, and sometimes,
[00:28:13] Busra Coskuner: yeah. Sorry. And, and another, another, uh, um, um.
Um, example from my time at Doodle, um, for example, so my team, so I was a, I was the lead product manager for the whole new business scheduling suite. Um, and so I was, today when you go to Doodle, then you see, um, uh, Doodle one on one and booking pages. So back then, uh, we were calling Bookable Calendar. So I was responsible for, for those two.
And one thing was, should we build a preview feature? It was a big thing, right? So technically, it was a big thing, but people were asking for it. And then we had to understand, like, why do they want to have a preview feature? Is it enough to, you know, just show it to them? Like I want to see how Mike like if the setting is correct, or is this something actually that they want others like their invitees to see?
Um, like what? What? What is it about? Right? So who needs to see the previous and why? And once we figured out, okay, it is about prestige. It's about image.
Emotional and Rational Product Design
[00:29:18] Busra Coskuner: It's not about checking, like, as you said, David, it's not about the racial thing, it's actually about something natural or even emotional, right? So job to be done, like it's an, it's an emotional job preview feature.
It's an emotional job to make sure that, um, what they send to their invitees doesn't look crap, right? So, and, and it's correct. Like what it shows is correct, but also it looks professional and is not crap. Because we were building, building tools for professionals that needed to look professional.
Embracing Boring Solutions
[00:29:46] Busra Coskuner: So adding to, to your examples, like it also goes into, into the direction of job to be done, right?
Why do they actually want this? Yeah.
[00:29:56] David Pereira: Yeah. And the example of CSV, what I wanted to say, sometimes we just need to make peace with boring solutions. We don't need to have fancy solutions all the time because I had a similar situation. Just
[00:30:07] Busra Coskuner: add the question mark thingy on it, right? So to explain what it is.
Sometimes that's
[00:30:12] David Pereira: Boring doesn't mean bad. I had a similar situation in Germany in one of the e commerce that I worked. We start a partnership with China and it looked very promising, but when I got to the soft engineers to talk with the soft engineers from the other company, they came up with an estimate, it's going to take us three months.
I said, I don't want to invest three months to understand if we have orders coming. And I look at them. I said, what can we do in a week? I said, a week at best, we can set up an FTP and we exchange files. That's what we can do. I said, good enough, because if orders come, then it justifies building it right.
Building to Learn, Then Scale
[00:30:52] David Pereira: So I said, like, let's just first build to learn, then we build to scale. And the engineers were laughing. They said, it's going to be a very ridiculous solution. It's not professional. I said, I don't care if it's professional at this moment, because I don't have the confidence the solution should be built at all.
So we did that actually in three days. And it turned out that. In the first month, we had two orders instead of 2000. I said, Oh, okay. So let's keep trying. The second month we had another two orders and I said, okay, it's better not to continue this. So I just put it very beautifully in the trash. Nobody cared.
And we just invested three days. So asking this question is like, what can we do in a week instead of three months? Some people are afraid because they take the three months as That's what we have to do. So no, no, no, no. I started simple. Let let's understand what we can do. So embrace a boring solution.
Sometimes it's fine.
[00:31:50] Busra Coskuner: Oh, if I can add another personal story that might be even the segue to your roadmapping, uh, topic, um, actually to. One thing that I also want to say is sometimes we don't have to validate and just do it.
Throwing Spaghetti at the Wall
[00:32:03] Busra Coskuner: I know, unpopular opinion, but sometimes we need to throw the spaghetti at the wall and see if it sticks, right?
So sometimes we have to do it. As an example, just this morning I posted how I gloriously validated if I should start my matcha business or not.
Matcha Business Journey
[00:32:18] Busra Coskuner: I didn't. I just, I just went on the market and I, and I took the risk and import matcha, imported that specific matcha. Started to sell here in Switzerland just to see if there is something be, I mean, there is something, there is a market.
I know it's commoditized. Everybody's drinking matcha. Um, and back then, um, so I started this like four years ago and back then there was no good tasting matcha. So my point was only about positioning it well so that it sells and I don't compete on price. Right. So sometimes you just have to throw it and see if it works or not.
And then, yeah, so, and then now we are scaling that. And now, um. But also tying it back to the point of of of what David said not testing your assumptions So I just thought we just have to put it into a premium positioning and then it's gonna work, right? So you still make those mistakes yourself and and now like this year we will do the proper testing with with Google ads on the on the real value proposition and and see which one generates the biggest amount of interest, right?
But to The other, um, example that might be the segue to your to your road mapping question. Same same point with the much, uh, business. Um, this is like what David said is excellent question. What can we do within this amount of time? So This year we had some time to to work on it. We means my husband and I and my husband.
So we we pluck the we we um are working with the fulfillment center now. So what we needed to do was build the API. That's what he did, built the API between our system and their system so that when we get an order. It goes through, and the fulfillment center has it. So we were doing multiple things simultaneously.
We were trying to get the contract ready with the fulfillment center. He was trying to get the API ready. He was trying to set up Shopify. So right now, it's running on a no code system with a combination of SpreadSimple and Card. Um, and so he was trying to, uh, get Shopify done. And then at the same time, I wanted to start with Google ads and start my experiments and so on and so forth.
And then at the same time, suddenly we were moving apartments. And at the same time we had to get new orders because we're, we suddenly had multiple more B2B clients. And we're like, what the hell is happening? So we have to order, we have to order. So at the same time we were doing this, um, organic certification at the same place, so many things at the same time.
And then we sat down and said, okay, cool. Now here's ending. We have two months. What.
Roadmapping and Outcomes
[00:35:06] Busra Coskuner: Are the outcomes that we need to have at the end of these two months, like at the end of 2024, we said, Okay, in December, we want to be multiple weeks in Berlin. That means ultimate outcome is if an order comes in or not, when an order comes in.
It needs to be sent out without our involvement, independent from us. That's the ultimate outcome. And then my husband looked at what he built and said, we're done. And I was like, what? We're done. You were saying we have to build the API. No, no, no, wait. It can be sent out without our involvement physically.
So the only involvement that we have is order comes through to our server. I need to check the order and then send it to the fulfillment center. And then it's done. And we're like, okay, good enough. Let's go to Berlin. So it was like that outcomes are the real magic with the roadmaps. And that is where experimentation and delivery meet actually, right?
Have we achieved that outcome that we have planned in our, on our roadmap or not, and if not, what is missing? And then the question, what do we still need to learn? By when in order to make which decision? So we start with the decision. Which decisions do we have? Like, what do we have to achieve the outcome?
Which what is missing? Which decisions do we need to make? What do we need to learn to make those decisions? What do we need to do now so that we have that learning in a specific time frame so that we can make the decision? Close the gap and achieve the outcome.
[00:36:55] Michel G: Um, I, uh, I got a question from Sam Joe. How do you make sure your test results are relevant?
Where is the line between valuable insights and anecdotal evidence? Which I think it's a, it's an interesting question. I mean, if you run an AB test or something where you can pull a lot of data, the statistical significance is something that you can. Relatively, um, analyze or, you know, come to a conclusion, but when you're running tests that are, uh, or you're, yeah, you're testing your assumptions and the, the approach is my, I don't want to say more esoteric, but not as clear cut, like where's the, um, you know, where do you draw the line and say, well, you know, this is enough for us to, to make a call, David.
[00:37:42] David Pereira: Oh, sometimes it's a good feeling. I will not say it's very scientific because often product is more like an art. So, of course, if it's a B2C, it's easier to run many tests. If it's B2B, it's way harder to do that. It's a different game. The thing is, like, When you are testing first, what is the learning you are trying to have?
What are you trying to understand if customers want? Are you trying to understand if it's viable? So focus on that and see the signs you get there. And one of the situations we have. Worked for wine e commerce and there was a huge discussion if we should build a blog and I remember look at them I said the time we're talking here I could have already written two blogs at least I said let's just see if people will ever care about it I said how I said let's just put in our navigation bar it takes five minutes we put there and we see if people click and they said are you crazy I said we just put there and we see what happens and then within this we could see that we put it very prominent it was in the primary menu It ran for a day.
We had less than 1 percent of people clicking there. I said, at least this title doesn't land with anyone. No one is clicking there. I said, we could try some other experiment to see if they would read and so on. Start with what you want to learn. Make an assumption what success looks like. And that comes with the gut feeling.
You can say, like, if it's something like qualitative, you can say, like, 3 out of 10 people are going to do that. If it's something more statistical, you can define. But many people ask me, like, how do you come up with this number? I said, it's more like a feeling. It's, it's not really scientific. I say, if we achieve that, we're going to do that.
And so on and so on. It's kind of setting the bar. What is the bar for you? Which is the level of confidence you want to get. So going back to the example of the finding, if we need a, an app or not for, for the business there. I said, like, I want to visit 10 car dealers, they were car dealers. I said, if I see at least 6 using the smartphone, I will pursue the app.
I actually didn't see any out of 10. So in this case, it was very obvious. But defining this part, and then when it comes to anecdotes and so on, this is very qualitative. So I would say anecdotes may give you the chance of creating experiments from that and see if it resonates with more people.
[00:40:17] Michel G: Um, there's another question, but, um, just before we get into this, um, I was wondering if, you know, when, especially in the B2B space, right, when you build something on you or you hear startup founders like pitching their idea and they get to the slide around competition. Right. And sometimes they're going to say, look, there's no competition.
It's a blue ocean. And I think you've talked about this, Bishra, in your post this morning. Um, it can be very either great or dangerous, but, um, sometimes, uh, they will disregard, uh, substitutes, right. And say, well, I don't have any direct competitors. So, you know, the, the, the way is open for me. When you build a B2B product and maybe, uh, David with Omoco, that's a great example, how do you, or do you look also at how your product exists in the entire ecosystem of your customers?
Like, I'll give you an example to be more concrete, you know, back in the days when I was at Plista, we had this ad tech platform, which was. You know, basically a, a, a mini, uh, meta platform, you know, for advertising focused initially on native advertising. And, um, we wanted to improve the platform and, you know, one of the team members said, I think we should add AI to this, uh, so that we make it easier for people to, uh, create their campaigns.
Right. And, you know, it's not a bad, it's not a bad idea. It makes sense, right? You, you save them time, but my view was more like. I kept pushing them and I said, look, people don't come to our platform to launch their first ad platform, their first campaign, right? They go to Google or meta. We are at the end of the line, right?
We, we get the, the crumbs in a way when. You know their campaigns are not scaling anymore. So the campaigns like the the ad creatives everything is already done, right? My assumption was that they just copy and paste what they've done in facebook and put it there So, um, I was trying to push them and you know, I don't know.
Um, who was right, you know, I don't I cannot tell you how the movie ended but um, it's you know, a typical discussion that i've had You know internally but also with with clients so How do you, is this something that you think about, you know, whenever you think about a new feature, like how does your product exist within the, the ecosystem of other maybe software products that your clients are, are using?
[00:42:57] David Pereira: Sure. You need to understand the whole landscape there. For example, with our target audience, when we look at smaller terminals, it's in the maritime industry, our biggest competitor is Spreadsheet. So that's how they often run and that means high, it's highly flexible and they will do whatever they want there.
And it's very hard to compete with this when you are creating a standard product. When you go to more stable, uh, terminals, like bigger terminals, they, they can be more predictable. They will have some other terminal operating system from, from the market. So I understand the position of different, some terminal operating system.
They will say. We do whatever we want, we customize. So then the terminal will pay for customization. Others will focus on deploying on premise and training the personal and so on. What are we trying to do is like, how do we make it different? We try to see like, what are the struggles that they have with the solutions that are available to them?
And then how do we position ourselves in a different way? So that's how we do that. So it's very important to look. At competition, not only the direct, but the others to understand your positioning and make decisions on that, but you need to know how you differentiate because if you really focus on, um, for example, some people will come to me and say, what I need is a way of selecting the columns that will be visible and I want to save that view and I also want to have a future for all columns.
What they are saying, I want you to create Excel online. Because that's how users sometimes will present their problems. Then I start saying, okay, good, help me understand. When you do that, what is that going to make for you? And then some people say, well, when I scroll down, I will see some inconsistency, and that will help me prevent problems.
I say, okay, now we are getting to the point he wants to find inconsistency fast. And that's how he finds right now. So users will not name the problem. You need to find that. So that's the thing about understanding because often the danger I see. People just build the feature that the competitors are doing without knowing why.
And that was a situation I saw happening in the bank industry in Brazil. I was talking to someone who works at one of the biggest banks, and talking about roadmap, he said he was very surprised because The roadmap was the following. We are going to match NewBank. So we are going to have feature parity.
So we are going to do whatever NewBank is doing. We are gonna, we do whatever to do, but better. So that was the roadmap, but then what happened at the end of the year, NewBank kept growing more and more and more because they, they know why they are doing what they are doing. There's a reason for that. But then the funny thing is like, once I talked to a product manager from NewBank and I asked about the feature there and he said.
Ah, actually this feature came from Revolut, it's a very interesting feature, I just copied it. Got inspired. So this thing of copying the competition, you need to be very careful. Because then you may create something just for the sake of creating. Maybe people like it, but you don't know the problem you solved.
[00:46:17] Michel G: Alright,
[00:46:18] Busra Coskuner: let's get It's a really good source for understanding, uh, what They are doing not so well so that you can differentiate yourself in that
[00:46:26] Michel G: way. Great. Let's get into the, uh, the, the other theme that I wanted to cover. Um, and we have a question that is pretty much a line.
Balancing Assumption Testing and Delivery
[00:46:38] Michel G: How can we balance the need for assumption testing and product development with the business pressure to deliver results quickly, especially when time is limited.
And I, um, I think it's very interesting. I mean, I was, um, uh, the, the. The CEO of the company. So I was the guy putting the pressure to deliver quick results. I was the bad guy. I was the evil in the movie, uh, or the villain. Um, how, um, how do you manage things? Right. Everybody talks about, let's say product discovery, and it's a great concept.
It's a great mindset, but the devil usually is in the details of when you start implementing things, you know, in the daily grind, so let's start with, um, you know, How you would manage the product engineering team and say, look, you know, we, maybe we allocate that much time on delivery that much on product discovery.
How do you manage that portfolio of activities? Bishra, you want to get started?
[00:47:41] Busra Coskuner: Sure. And then I'm very curious what David has going to say, because David is the CEO. So
exactly. You're the other guy. Um, no. Um, so here's the thing. Um, It's a very difficult conversation to have. I have put the same pressure on my husband. Like, why haven't you finished the API, right? So, um, it's a, it's a very difficult discussion because, um, and there's no good answer. It's, it's always a wrong answer.
It's always a difficult balance because, um, like whenever I saw a company who has tried to say like, okay, so much percent of our, uh, sprint or cycle or whatever. Um, We're going to focus on, I don't know, building new stuff and so much percent of that it's going to be for bucks and so much percent it's going to be for whatever.
Then you end up in, in not knowing, like, what is the percent? I mean, how do you even calculate that, right? Is this the number of tickets? You can gain that. Is this the story points? I mean, you can, I mean, story points you can gain, right? So why do you need story points? Is it like, by what do you want to measure how many percent or how much, how, how many percents you have, whatever, um, spent on whatever you, you can't.
So my, the way how we did that at Doodle was, um, common sense. So that's a, that's a discussion to have with the cross functional team to say, look, guys, ladies, gentlemen, whatever, like, this is our goal. This is like, we have three months. Okay. This is what we have to achieve. These are the unknowns that we have.
This is like this feature. We know we want to build it. We don't even know how to build it today. By when, again, the best question, like by when do we have to have. This answer the concept the assets they whatever and then it is planning right so it is some sort of planning um and then at the same time you are in the you are you are in the grow in the go right so you have your cycle I don't know maybe you you work in two week cycles and and then you see what is like if you have enough.
To build because we have to deliver that by this date. And yes, states are still a thing, and they will always be a thing. And we have to deliver that by then. Then we will do that. But at the same time, if we can anticipate, and that's the biggest point, right? If we can anticipate that after two cycles, we don't even know what we're going to build.
And we have to pick some people from the from the team and say, focus on discovery while you While the rest is building that it's a there is no perfect answer to that and and getting the buy in from management is difficult because they do expect something by that date, and therefore, it's ideal if you can agree on outcomes to deliver by that date.
So that keeps you flexible, right? So this is the core of agility playing with the scope. Um, but at the same time, If you have to deliver an output by a specific time, then you make sure you deliver that, again, play with the scope and somehow squeeze it in to do also some discovery activity. Like, there is no perfect answer to that.
And now, David, tell us how you are the evil guy.
[00:51:24] David Pereira: I'm an evil guy with a product mindset, so it makes a difference. Still
[00:51:28] Busra Coskuner: an evil guy, no? Yeah,
[00:51:31] David Pereira: I put some pressure for delivery, but I focus on the following set of the telling the team what they should deliver by when. I say, like, we need to ensure that we upgrade our users.
We should not deliver more features, like we look at. And I say, yard planner is a critical role in Eternal. How do we make a yard planner a better yard planner? So that's the question we need to answer. So we need to ensure that they can find this and that and so on and so on. How we do it, I don't care.
And I like doing discovery without talking about discovery. Because sometimes I get so trapped into, like, What is the process of discovery? What is that? And so on and so it's just part of the work. So sometimes I agree with what you said before. It's you don't need to validate everything. If the cost of delivering is so small, you just deliver that and you learn from reality, but you need to decide if you want to keep that in the product.
So it's very important because it will create some learning because sometimes the release
[00:52:32] Busra Coskuner: is the experiment then. Yeah.
[00:52:34] David Pereira: Yeah, because sometimes you start discovering something and you discover that, I don't know, for a week, but the development of that would be two days. So I say, why on earth are you doing that?
Just deliver the thing and then learn from reality. So you need to be mindful. But what I do with the team is like Part of the team works more towards the future and part of the team works more in the present. So that's what I want. I want a balance between future and present. I don't name percentage on that.
The product tree, I want them to keep looking at the future. What is coming? So what is important? Like clarifying the problem space. And once we start going to the solution space, I want that to get, I want everyone to explore that, understand the context and so on. And we can come up with ideas for, for the future.
So the team can implement. potential solutions for that. But even with this exploring the future, there might be moments that someone say, we need to run a more technical experiment here, get the rest of the team involved. So do that and so on. But I focus more like, uh, on what do we aim to achieve? And I coach the teams to balance present and future.
When I realize the teams are too much on the present, I say that's dangerous because then, uh, it means we are going to make several compromise. Two step towards the future. So that's not good because then the decisions will be suboptimal. There'll be assumptions which are dangerous and not tested. So let's ensure that we have a sustainable balance.
That's what I try doing with the team. And I like capping investments. So saying like, this is, I asked product managers to define what is a worth investment for this. So what is the value behind this solution? Okay, this is a very valuable solution. Maybe we can invest a whole sprint into that. And it is an okay solution.
It's just a standard. So let's invest a maximum of a week, nothing more than that. So then we think more about value instead of going to the team and all the time as like, how long does it take? I say, how long we have to invest in that and see what we can do about it. So I, I like having these conversations and focusing more, one of the things I like driving, like focusing more on doing the work instead of talking about the work, because that freaks me out that people keep talking about the work.
And I say, seriously, a meeting with 10 people, that doesn't help. Let's just do something that helps, that creates learning.
[00:55:00] Michel G: Yeah. And I think you say you like to cap the investment. I think what I found also useful was to put some, some of the timeline where we say, look, you know, we're, we're in it for, you know, this quarter.
And if, if, if we're, we don't learn enough or if we're not getting the results, like we pulled the plug, right. So, you know, before you kind of get started, you know, that you have a one hand on, on the plug. Um, I'm looking at the time time is, is running. There's just one last thing before I let you go. So first of all, uh, people, uh, you're more than encouraged.
I encourage you to follow, uh, David and Bishra on LinkedIn. I think it's kind of a good channel to get started and then you can discover, uh, their, their whole universe, you know, on their web, uh, the websites. Uh, but just before I let you go, I'd like you to, to give me a. Um, your, uh, last advice, and both of you have talked about this in different, um, environments, let's say, which is, um, kind of less is more in a way.
Um, there's one, um, quote from Antoine de Saint Exupéry that I like, which is, uh, Perfection is rich, not when there's nothing left to add, but when there's nothing left to take away. I'm pretty sure it sounds even better in French, but I'll, I'll, I'll stick to English for now. And you've mentioned something very similar in one of your presentation, David Bushra.
You've talked about dropping metrics that, um, you know, why track data when there's, there's, you know, after a while, there's nothing to, um, Uh, there's not enough, let's say value in tracking specific metrics. So can you, both of you in a couple of seconds before we go to the, uh, the ad, I'm kidding. Um, what, what's your tip?
Last advice, you know, for, uh, people listening to us on how to make sure they keep that mindset of removing and simplify maybe, uh, this run, you want to jump in?
[00:57:03] Busra Coskuner: Sure. So what helps very much is having a, having an audit like scheduled in your calendar, focus time to, to check the numbers, watch metrics, um, look into your data, B2C easier than B2B, and then decide.
Are we, like, do we really need this feature? Do we really need this tiny little thing here? Do we really, like, does this really add value? That's a very general advice, but that's kind of like the couple of seconds advice. Do an audit, um, frequently scheduled in your, in your, in your calendar. And in order to do that, you have to set the success metrics per feature and understand what does success mean, right?
[00:57:50] Michel G: Great. I like that. So scheduled, uh, say no, or, or delete, uh, meeting, uh, David, what about you?
[00:57:58] David Pereira: Yeah.
Ruthless Prioritization
[00:57:59] David Pereira: And in this direction for me, it's about ruthless prioritization. So I started the week asking yourself, what do we want to achieve by the end of this week? And then you look at what do you want to achieve?
It's one goal and you define that. And then you look at your calendar, everything that distracts you from that goal. You just take the courage of clicking there saying, I'm not going to show up here, here and here and here, you may send a message to give something and so on, but you don't need to take ownership of your time because if you don't, then the calendar is going to define what you do and then you don't have the time for important things.
So it is about reflecting. And taking action saying that's the goal I want to achieve. So what do I need to do right now to achieve this goal and keep doing that? If achieved before, maybe take something else, but you need to have the focus because what many product teams lack is focus to achieve something like, for example.
We invest 20 percent in technical debt, 10 percent in bug fixing, and then another. This just doesn't work. Focus works. If you, if your goal is to kill the technical debt for this week, for the critical things, define that. Then focus this week to do that. Only do that. And all the other things live for later because this ruthless prioritization is what enabled fast progress.
Can have deep work without that. We are just, uh, having a lot of context switching and that will kill not the only productivity, but also motivation.
[00:59:32] Michel G: Great. Love it. Root test prioritization. Easier said than done though, but that's definitely the way to go. Great. Well, thank you so much for your time. I really appreciate it.
Thanks for our attendees. I, um, the replay will be available, uh, as well. So we'll make sure that, um, the, um, insights and, uh, wisdom of both, uh, Bishra and David will be shared. Um, you know, throughout the world. So thanks again, uh, for joining us, uh, at last, uh, make sure that you follow them and, uh, have a great rest of the day.
[01:00:08] Busra Coskuner: Thank you for the invitation.
[01:00:11] Michel G: Pleasure.
[01:00:12] Busra Coskuner: Bye.
[01:00:13] Simon: Thanks again for listening, I hope you enjoyed the show. Make sure you subscribe to the podcast. And as usual you can find the show notes at stunandawecom.
