About this talk
In this talk, Petar Gurcheski, a staff software engineer at Miro, discusses the concept of the industry standard hoax and how engineers can contribute to better product decisions. He explains that while industry standards can simplify decisions, blindly following them can lead to misaligned solutions that fail to meet actual user needs. Petar emphasizes the importance of evaluating industry examples critically and not limited to familiar paradigms or big players. He highlights the necessity of understanding the context behind industry practices and adapting them thoughtfully to fit existing product frameworks. By fostering a product mindset, engineers can challenge assumptions and collaborate more effectively with product managers to deliver genuine customer value.
Full transcript
Uh, welcome. Can you guys hear me well? Yeah? Okay, awesome. Uh, welcome. Uh, my name is Petar. And today we're going to talk about what I call the industry standard hoax. And how engineers can help steer product decisions. Uh, just for my knowledge, are most of you engineers or less engineering managers and so on? Maybe by a show of hands? Okay. And most, but not all. Cool.
Uh, yeah, so a little bit about me. Uh, my name is Petar uh, Gurcheski. And I am a staff software engineer at Miro. Yeah, I have a QR code here with some links, but it's also going to be at the end of the presentation, so you can just take a look at it uh, then. So, let's begin. Um, at some point in my career uh, one of
our heads of product uh, I used I'm a Looney Tunes character. He used to work for Acme. Uh, basically said something like this. That customers of SaaS products are accustomed to industry standard functionality. And then our product needs to reflect that. this sentence carries a lot of weight. We really like to follow industry standards. And therefore, when somebody says we almost take it for granted. We don't
really challenge that authority. We tend to think that yeah, obviously we need to do something that's industry standard. So, let's just go ahead and do it. And why is that? Let's unpack a bit. So, what is an industry standard? And it's kind of in the name of it. It's a standard that's uh, used across the industry. Uh, in our case, I guess tech. And it could be
formal. Could be like a a nice old standard for enforcing security where you actually have a governing body that enforces the security the standard or you could have something informal like a QWERTY keyboard. As you know, there is also other types of keyboards like Dvorak or maybe the language based ones like Azerty and so on. But most of us would agree that even though it's not a
strong standard, if you try to sell a keyboard with just the letters and keys all jumbled up, you're probably not going to make many sales. why do we desperately want to follow industry standards? For one, it's easy. Let's say we want to build an e-commerce website. We can start from scratch. We start thinking, okay, I probably need a catalog. I need some sort of search. Um yeah,
obviously people need to be able to pay, otherwise how is it e-commerce and so on. And you'll find that this exercise can keep on going and going and going and you'll make mistakes and you'll have to redo things. Well, the easier thing to do is to just look at something like Amazon who's been in the industry for 20 some years now who've already spent millions in R&D
and have already made all the mistakes and you can just take their learnings and basically copy what they do and you already have a working website without having to really do all of that. And the thing with something like Amazon being in the industry for so long and so ubiquitous is that it ultimately also becomes what customers expect. They expect that these e-commerce websites all work the
same way, right? They expect that when you click add to basket, it actually adds to some basket that you can then visit and do the purchase. If you were to directly when they add to basket send them to the checkout, they'll probably not be very happy, Uh to give you a different example, maybe a bit more relevant to our world, if you're implementing a website and you
want to implement multi-select and you use a radio buttons, you're not really being innovative, you're being a bad designer and the users will hate you for it. And here lies the hoax. Because we so desperately want to follow is why this sentence carries so much weight and we tend to basically take it for granted almost like, you know, those infomercials when you have uh toothpaste uh ad
and then say nine out of 10 dentists recommend this toothpaste, we just say, "Okay, yeah, I guess that's cool. Yeah, let's just buy the toothpaste and carry on, right?" Well, not exactly. Because what this can lead to is that you could actually make a miss. Your solution might actually not be a match. And what then happens is that yeah, you have spent a bunch of time implementing
potentially nobody wants or it just doesn't really work well. Now, you may maybe wondering why should you care? Uh special specifically for the engineers, like why should you care? Like at the end of the day, there is somebody responsible for figuring out the problems, the solutions, and the requirements and I'm here to implement them. especially in this age, when coding is getting commoditized, uh just blindly following
requirements and implementing them can uh be detrimental, right? Uh at some point maybe anybody would be just be able to do that, right? I have my requirements, I write a spec and I send it to your LLM of choice, coding tool of choice, and it dishes out what I wanted, right? adopting a product mindset as an puts you in this very favorable position. Because you are the
person that properly understands your technical stack, hopefully better than the LLM, at least for now, and is also able to resonate with a customer, their problems, and understand how you can solve them. So, you caring about this basically puts you in an advantageous position. Right? So, let's say somebody comes up to you and says, "This is what we should do because this is the industry standard way
of doing it." Right? And what do you do, right? Or maybe you are a person who's looking for an industry standard solution to your problem. Well, there's a couple of things you can do. The first step is to look for more industry examples. what do I mean by this? You see, when people look for industry examples, they tend to fall into some traps. They tend to stay
in the comfort zone. To give an example from, again, our career, right? Uh we're as developers, we usually have a preferred programming language. Maybe that's JavaScript. And what this means is that anytime you want to start a new project, comfortable thing to do is to just use JavaScript again. And I mean, JavaScript today can be used for virtually everything. I think I don't think there's any stack
which cannot be somehow done with JavaScript. But whether it's the best thing to do, that's where it gets questionable, right? Front-end development, obviously. Graphics programming? And last time I checked, it's probably not the best. If you think that's wrong, you can come lecture me after the after the talk, but that's pretty much it. so by looking at more examples, you basically will potentially find the best tool
for the job. Now, another trap is looking to big players for inspiration. So, going back to our Amazon example, right there we just looked at a big uh big player. But, let's consider another big player. How about Google, right? That also seems like an easy thing to But, uh I don't know how many of you guys know, there's this really funny website called Google Graveyard, where you
can actually go and see all the products that Google made that ultimately they discontinued and they ended up in this graveyard. So, if you just took Google at face value and you tried to copy what they did, and you made your products work exactly like theirs, and it's one of those, your product would be right there next to them, buried together. thing you need to do is
to challenge yourself to escape your comfort zone and look at more examples. Look at more alternatives. It's okay to look at the big guys, but maybe check what other big guys are also doing in that space, if there are any, Now, the next thing, kind of keeping in the same theme, is that you should really focus on examples from your industry. what people sometimes tend to do,
but they shouldn't do, is underestimate just how broad the world of software is. They're like so many tools, and more and more coming up every day, especially with this whole AI boom, right? So, if you just look at an example without really thinking of where that comes from, you might, again, fall into a trap. So, let's talk about, I don't know, billing. Right? For a very long
time, billing worked in the way where you had like a freemium model, and people could try out your tool, and then for a fixed fee, a license fee, usually per seat, maybe in a few tiers, like higher tiers give you more features, you could use the tool as much as you wanted. Right? You can create as many Miro boards, you can I don't know, as many Google
Docs or whatever you want. But with AI, that doesn't really work that way, right? If you gave your clients a license fee, which they once they pay, they can use your AI tool as much as they want, you'll probably run out of business because we all know how expensive those tokens are. Which is why even when people do offer kind of like a license seat thing, like
Claude, right? A subscription, they still give you a limit. They're like, "Yeah, you can pay for pro, but it's, you know, you can use it for a month for $20. You just have to stop every X amount of prompts because otherwise we'll run out of business. And what this also leads to is people comparing apples to oranges. So, if you're somebody that's building a data warehousing solution,
it's probably a lot more interesting to look at what Snowflake is doing or Databricks, or maybe something tangentially related like Grafana and so on, instead of looking at what Figma is doing. Because Figma might be a great design tool, but your problem space is data warehousing or analytics. So, while you may take some inspiration from there, you're probably better off looking at examples from your industry. Because
finding your niche and narrowing down your research makes you more effective and realistic and efficient. Going back to how many software tools there are on the market, you cannot realistically look at every example before you make a decision. So, might as well look what's most relevant. the final bit, and maybe the most difficult one, is to evaluate product fit. Going back [snorts] to that Amazon example. The
way I said it was like, "Hey, we want to build an e-commerce website." So, we're starting from scratch. You can basically give a prompt to Claude and say, "Yeah, build me an inspired by Amazon." And you'll probably get to some solution. But the fact of the matter is a lot of us are working on products that are maybe have existed for 15 years and have somehow made
technical debt worth 20 years, right? Even though there's only been in in um on market for 15. And is then it's then that we realize that industry standard solutions require industry standard products. And unfortunately, through 15 years of patching, hacking, custom implementations, uh filling out specific niches for specific customers, your product is not standard. And trying to just uh plug in an industry standard solution there could
lead to trouble. It would be like trying to fit a square square tile into a triangle-shaped hole. You will have a really hard time doing it, and you'll probably break something whilst doing it. So, what can you do instead, right? We still want to be industry standard. Well, maybe what you can do is actually try to understand the reasoning behind that solution. Why did Amazon or Google
or whoever your competitor is, doesn't matter, why did they decide to do something this way? What benefit did they gain gain from it? And maybe there's a way where you can adjust this learnings and fit into your product. Or maybe you can, let's say, discuss with your product manager and tell them, "Hey, I know you want to get from A to Z, but there is also 24
other letters in the alphabet that we can maybe make a pit stop at. Hopefully not all 24. We don't need 24 iterations, but you know, maybe you stop at the letter J, then a little bit later at letter M, and maybe a W just close to the end, and then you reach your ultimate goal. Because at the end of the day, your goal, as well as your
product manager or any stakeholder, is actually solving customer value. If just pushing yourself to fit this solution into your product at any cost possible will lead to delays, will lead to performance scaling issues, and will lead to ultimately missing the goal, which is providing customer value. And final step, well, in principle, that's it. My point here, and what I'm trying to raise, is not that you should
completely abandon your engineering hat, throw it away, and just put on product hat, and become a product manager. The idea isn't that you're supposed to sit down and do intensive market research, or do focus groups, customer interviews, and all of that. Obviously, if you have the capacity, chance, and you want to do that, there's obviously welcome. There's plenty to learn. Uh but the idea is that maybe
with adopting a little bit more of this product mindset, and starting to question product decisions, the same way you would question your technical peers in their database choice, or language, tech stack, whatever, you could actually become a sparring partner for your team, for your product manager, and you can both come up to a solution that just fits your problem space better. >> [snorts] >> There is actually
one more thing that you kind of need to remember. >> So, you'll be presented something, you'll think it's really bad. You'll spend all this time researching, doing everything, and you'll not be able to convince people. And you will get overruled, and at the end you'll still have to implement uh a specific solution in a specific way. And this can happen for many reasons. It could be that
uh lack of experience, it could be ego, or you could just be wrong. I mean, I know that's usually not what's most obvious to us, but we could we And the fact of the matter is there's two paths that you can take. You can either disagree and commit, or you can block the solution forever. And the truth is that a bad plan is still better than no
plan. if you implement a bad plan, you know, maybe you'll make some mistakes. Maybe there will be a few iterations extra iterations that you'll have to make, but you were at least you will at least be trying to solve customer problems and provide customer value versus the alternative where you just stay passive, and you basically open the gates for your competition to just steal your your customer
base. when you do get validated, and it turns out that you were in fact right, try not to be this person. Try not to be the person that just goes around and tells everybody told you so. Uh yeah, even if you practice it in front of the mirror for a very long time, and just played all those conversations over and over over again, hyped yourself up to
I have the tiger music, and yeah. So, that was it. Thank you for uh attending this talk. And yeah, if you want to follow a little bit more about this, there's my um contact there, and if you have any questions, you can come and ask me after, because there's not really a microphone to give out. Awesome. Thank you.
