Building a Product From Scratch with Roman Kudryashov of Recommended Systems

Kayla: [00:00:00] Thanks for tuning in to Product Chats. On today's episode, I talk with Roman Kudryashov, who is the founder of Recommended Systems, and we talk about building out a product team and also building a product from scratch. So hope you enjoy the show and don't forget to leave us a review.

Hey Roman, thanks so much for coming on today.

Roman: Hey thank you so much for having me.

Kayla: Yeah. Well, in a minute or less, can you tell us a bit about yourself.

Roman: Sure. So my name is Roman Kudryashov. I am currently the CEO of Recommended Systems and Dragon Blood Bomb. Before I started those two companies, I was actually director of product at Pager.

And previous to that I've held a number of other roles, both in the product and marketing space including as a senior director of marketing, as a director of digital. And I've had a chance to work in a number of different industries from a software to physical products, from luxury sector to healthcare.

So very excited to talk about that.

Kayla: [00:01:00] Yeah. So let's actually dive into that a little bit about like where you started and what that journey has kind of looked like and kind of diving into how you got into product.

Roman: So I think that my road to product like many other people was non-traditional.

I don't think that or at least five, 10 years ago there wasn't any courses that you took in college that were explicitly product management. Actually started out my career in journalism and communications. And with that that was when everybody, every single newsroom was going through a transition to digital where print publications were kind of fading out of style and everybody needed to have a web strategy, a digital strategy.

So as part of that, I had to transition into learning about, you know, how digital products are created what works, what doesn't how people come in and interact with web properties, with software properties that are being put together. That led me somewhat directly into marketing where I had the opportunity to think about even deeper how to [00:02:00] acquire users how to engage with them and then how to create value for them.

When you end up going into the marketing space, there's, there's often two areas that, that people tend to specialize in. One is the traditional realm of marketing communications, and then another one is product marketing, where you're thinking more than just about advertising, more than just about, you know, email strategies and things like that.

And you're thinking about how do you build a relationship between the company or the product that you're building and the consumer that is on the other end of it. So when you think about that sort of relationship, you find yourself in a cohort alongside a number of other departments, product being one of them.

And so as part of that, I found that my marketing work was starting to deeply overlap with solving the problems that product was also overlapping. So I had a chance to informally start working on that. And then eventually I transitioned into a more full-time product role where I was responsible for building out first [00:03:00] internal tools that were really informed by the customer needs and by the company needs.

And then to an explicit role as directing and building out a product management team.

Kayla: So with that, let's actually talk about like building out teams and what kind of piece of advice or what that looked like for you.

Roman: So when you build out teams there's a number of different considerations. So I've had a lot of experience coming in to areas where a team may not have existed before or where a team needs to be rebuilt both on the marketing and on the product sides.

I think the biggest questions coming in when you're starting something from scratch is – what is it that you're, you're actually trying to accomplish? When you come into a company oftentimes the initial guidance that you're given is more so in the form of a question or more so in, in the form of a challenge. We have an an opportunity of some sort, and we think that product or we think that marketing or we think that product [00:04:00] marketing is the right way to address it, but we don't have the internal expertise to figure out what is it that we should do here.

And so when you come in, the first thing that you need to do is figure out how does this department actually align with the business goals? Where does it fit in? Do you have a fully robust engineering team that you're partnering with or are you relying on an agency? Do you have a communications team that can augment the things that you're building or is it going to be the responsibilities of the product team to own some of those communications?

And so as you go deeper into that, you start to figure out what kind of expertise do you need to bring to the table. And then also, what kind of processes do you need to have in order to enable the department to succeed? The reason I say that is because, depending on the business that you come into, you may need to implement different types of processes and different types of goals.

If you're in a more enterprise organization it may a very real situation where you're coming in and working with predefined contracts that you have to deliver on, and you're responsible for figuring out how to [00:05:00] deliver that. Whereas if you're in more of a direct to consumer space, the requirements of the product team may force you to have to iterate more on a theme to figure out what that looks like.

And then the most important thing is when you are coming in how to show meaningful progress. I think anybody coming in, whether you're at the manager level, whether you're at a director level, where whether you're at a leadership level, you have to figure out how do I solve the problems that the company has and how do I demonstrate value?

And then when you do begin to demonstrate value, you begin to build trust. And with that trust, obviously the team begins to grow. Your capacity to take on additional challenges begins to grow as well.

Kayla: I kind of wanna dive into like how do you actually hands-on demonstrate that value and what does that look like?

Roman: So I think that answer is a little bit context specific. if I think about, let's say in an enterprise organization the value of a product team may be around creating utilization. For example, at Pager, one of the things that we did [00:06:00] was we had a B2B2C model where we worked with payers and we helped our clients get utilization on, we help them get utilization through their membership.

So as a product manager, one of the most important things for you to consider was to be able to come in and say, not just how can we build a product that conforms to the ecosystem that our clients have already built cause we were in an embedded solution. But also how do we ensure that within this embedded ecosystem that we are starting to drive utilization.

So when you think about the results, it, you had to think about it in, in a number of different ways. One was about compliance with our clients. Another one was about how end consumers are beginning to use it. Even when you may not have many of the traditional levers of gaining utilization because you don't control that direct relationship with them.

Whereas when you are a let's say a direct to consumer company, some of your metrics might [00:07:00] be more so around the traditional levers that you look at. So what do your referral rates look like? What does your utilization funnel look like? What do your returning users look like? And optimizing for that.

And when you are launching a new product in general one of the things that you have to look at is the opportunity even real? I think one of the things that's extremely challenging, especially when you're launching your own business, is to be able to answer the question, not just, can I get people to use this thing?

Are they coming back and are they using it? But is the thing that I have created generating enough value that somebody is willing to pay for it? So in that sense product management is extremely deeply intertwined with the business model and the monetization strategy

Kayla: It's always tying that back to the company goals, right? Our goal is to drive more revenue or our goal is to do this. And I've seen a lot of successful product teams giving their kind of teams the [00:08:00] flexibility to choose their own path and obviously interview customers and figure out the why of why do you need this and figuring that out.

But always keeping that bigger picture in mind of like, what are these company goals? And not just feature building because a customer wants it, but actually building stuff out that aligns with what's our bigger company vision and where are we trying to get.

Roman: I actually think that that's a really good way to look at it.

One of the things that I hear from product managers every once in a while, and one of the things that I see in the industry is that it's, it's very easy for product management to get caught up in the software development cycle , right? And you see articles on Medium or on personal blogs that are talking about the delivery of features or the successful delivery of features.

Like we shipped something in a timeline and it had no bugs. And that's wonderful, right? You know that as a company, we all wanna be able to ship software that has no bugs, that is getting utilization. But when you think about the role of different [00:09:00] departments in a company, there's, there's really a trifecta in, in that world.

On one leg you have product management. On another leg you have design, and on a third leg you have engineering. So when you think about it in that sense, what is the unique thing that product management brings to the table? I'm actually gonna answer that last. Because when you think about the successful shipping of features without defects that's really a question of engineering.

You know, has the engineering team built things that are reliable and that work? And likewise, are people using it? Is the experience that is being created, well, that's really the domain of designers to come in and think through what are the user needs? How do they interact with the interfaces that you've designed?

How do they go through and navigate the application to be able to solve the problems that they're coming in to solve? So then the question goes back to, okay, well what does product management do? And what product management does is it answers the question of what is the important business questions for us to tackle?[00:10:00]

Right? When you write a PRD as an example, the thing that you are trying to solve for or answer is – what is the thing that, if we solve this problem, we'll be able to create business value? And then, as part of that, you begin to define the KPIs around this. So if we solve this problem, then we expect to see some sort of increase in utilization, or we expect to see some sort of increase in revenue, or we expect to see some sort of new opportunities or growth being opened up.

And then, in addition to that, you also solve for the question of, okay, we, we said we're gonna build this thing, we're gonna solve this problem. We said that we're going to get these kind of results and we're gonna measure it in this way, and then we are going to roll it out in a specific way. So not just, hey, we're gonna work on these things, but how do we get these things into the hands of people.

Because very often if you've built a really fantastic feature and you've shipped it and it's there, but nobody's using it, then there's not really a way [00:11:00] for you to get the value that you promised. So what product management brings to the table is this explicit business focus. It's not project management, it's not trying to be a scrum master team.

It's not managing the software development life cycle. It's, it's solving explicitly defined business problems. And that's where the creativity, that's where the logic, that's where the analysis comes from. And the reason why I say this is because there are plenty of times where the solution doesn't necessarily have to be a software solution.

Even if you work in the software space. Sometimes it's enough to build a landing page or to run a pre-registration campaign, or, especially if you work in an enterprise side to equip salespeople with pre-selling materials to evaluate if people are even willing to pay for something, if people are willing to buy a certain feature before you build it.

And the reason I say that is because one of the other things that product management tries to do is to say that, look, engineering resources are expensive. It [00:12:00] requires a lot of people to build enterprise software. It requires a lot of people to build scalable software. And so you wanna make sure that when that team is working on these projects, they're not wasting their time.

So as part of that you're trying to figure out – how do I solve the right problems? And then explicitly you're letting the designers, the engineers be participants in that process of creating solutions. The designers have a ton of expertise from their side. Thinking about the users, the engineers have a ton of expertise on their side, knowing the systems and the architectures and what might be a simple solution versus what might be more complicated.

And so again, going back to that core point – as product management, you're really trying to figure out what are the right problems to solve as a company. And if you can do that, then I think you'll be extremely effective.

Kayla: You bring up a great point, right, about not wasting engineering time because it's, it's really expensive.

And so I think that goes into like actually something that's really important as a product [00:13:00] manager or even as a product leader is actually like getting in the weeds, right? With your customers and actually sitting down and understanding their A, interviewing them and then taking a step back and understanding what is the impact and what do they actually need.

What's the pain that they're solving versus, hey, let's build this out. Hey, engineering, build out A, B, C, D. I know in some cases, right, you mentioned like in the enterprise space you've promised things and that can be different, but in a lot of companies it's, hey, let's actually take a step back, and that's like a huge role of product is let's think of this on a bigger picture and what is the problem that they're dealing with? Not let's build this feature like you mentioned, right? It could be a different landing page, it could be something else, and it's not always that like, let's build out this feature. It's, hey, let's take a step back and actually think critically about what they actually need and also the different solutions that we could potentially create.

Roman: Yeah, absolutely. I think that if as a product manager you're not speaking to customers or, or you're not [00:14:00] addressing customer needs, then you're missing a core part of your role. And I say that with caveats, of course. There are times where, let's say, you can't speak to customers for whatever reasons.

Maybe you are in the healthcare space and you can't talk to patients that might be using the platform or patients don't want to talk to you. Maybe you're working with an enterprise organization and your direct relationship is with buyers as opposed to the end users of the software. Even so, you have to find opportunities to to talk to proxies for the customer.

And not only that, you have to find ways, even again, going back to the example of enterprise software, you have to be able to translate the certain problems that people are coming to you with, with how you might be able to begin solving it. That, that translation layer is extremely important because more often than not people come to you with solutions as opposed to problems.

And when they come to you with solutions they do two things. Number one is that they make a [00:15:00] ton of assumptions about what already exists and, and what could be done, right? And those solutions might be extremely costly. They might be extremely difficult. They might not even solve the right problem if somebody hasn't gone back to the source and said, well, what is this actually a solution to?

And, and why is that even a problem? There are plenty of times when I've come in and people think that the problem is one thing, and so the solution that they come to the table with is a direct result of that. Where if you think deeper about the problem, well, the reality is that, that that's not the core problem.

It's actually a symptom of the larger problem. And so you have to go through a process of asking "why" multiple times. Why is the fact that, you know, somebody's not going through and clicking on this button a problem? Well, it's because we built this feature out and we want people to use it. Well, why do we want it to use it?

Because we think that there might be certain results that you get from that. And every time you go and you ask why it opens up the problem space more and more for you. And that opens [00:16:00] up the variety of solutions that you have so that when you do choose to work on it again, you can go back and say, hey, we solved this thing and we've got real results from it.

And meaningful results from it. The other thing about that conversation is again, a lot of people think in terms of solutions and, and I admit I, fall into this trap as well because it's extremely easy to do this. And because people coming into the product space have a lot of taste, right?

They've, they've used a lot of different products. They have ideas about how products should work, and so it's very easy to immediately default to what a solution should be. But, again, going back to that core point, when you are attached to the problem, that means that you are attached to creating some sort of value.

And the solutions are multiples, right? Any problem can have 10, 20, a hundred, a thousand possible solutions. And really, it's up to the designers, the engineers, and of course, you know, you can, you can weigh in as [00:17:00] a product manager that sales can weigh in as, as, as managers of, of those relationships.

Marketing can weigh in. The point is that, good ideas are not siloed within the product management space. Anybody can come to the table with a good idea or a good solution. And really, by staying attached to the problem, you have this opportunity to evaluate all the possible solutions and ensure that the things that you work on are really the ones that truly solve the problem, as opposed to simply making somebody happy because we, we did explicitly what they asked us to.

Kayla: So on that piece right, about getting kind of to the why and not solutioning, but actually looking to the problem, let's actually talk about building a product from scratch and what does that look like for you?

Roman: Man, building a product from scratch is tough. I do think that a lot of times when you come into a company, you're often coming in and there's something that already exists, right? Whereas when you're building something that has never existed, [00:18:00] then, on one hand it's an extremely exciting opportunity. You, you can solve anything, you can create anything. But, at the same time, going back to that previous point that, you know, engineering time is expensive.

And so whatever you choose to work on, you need to make sure that you're creating the most value right away. So the decisions that you're making are really in line with the business outcomes more at the beginning than at any other point. Because, especially when you're getting started, and I'll, I'll use the examples of starting a new company.

When you're starting a new company, you have a limited amount of time, you have a limited budget and you have a very limited number of people there. So you can't afford to spend a lot of time figuring out, building out a bunch of random features.

So the most important thing that you can do at that point is to invest the upfront time in talking to customers, understanding what their pain points are, understanding if they're willing to pay for things. And in fact doing things that don't scale. Again, going back to the idea that sometimes a landing page can be more [00:19:00] effective than an actual product solution, there are times where you may want to imitate something like AI.

To just see if people are going to use certain features where you're going in on the backend and you're figuring out the answer to these things. For example, if you're building a chat bot, you may wanna start by not having a chat bot at all, but just talking to the customers to understand what kind of questions are they coming to you with.

Or, if you're building some sort of automated service, then maybe it looks automated, but you're actually doing the work on the backend. And the reason for this is because that way you don't have to over-engineer a solution that you don't know if it's actually the right one. I think a lot of people come to the table especially when they're, when they're trying to start something new, having an idea and having this rough opportunity in mind, and that's awesome.

That's what gives you the initial direction. But then, once you have that, the most important thing to do is to actually talk to the customers and see how [00:20:00] they use it, if they're willing to pay for it, if, they're providing any sort of feedback or if their behaviors are very much in line with, with what you expected before you invest in the time to optimize for that.

And, and again, the reason for this is because once you optimize it, you've essentially locked it in. And especially when you're building something new, the sort of feedback and guidance that you're gonna get with your first 10 users or with your first hundred users is gonna be extremely different as your next thousand users come on, or your next 10,000 users.

And then again, as, as your first million users come on, the challenges in the architectures that you're going to have are going to be totally different. It's, it's effectively a different architecture, a different product, a different company in terms of what you need to do to staff for, in terms of what you need to build for.

So the most important things at each of those stages is to talk to the customers, learn from them, see how people behave in reality as opposed to in the assumptions that you have made about their [00:21:00] behaviors

Kayla: I think just to echo your point, right, like listening to your customers at the end of the day, whether you're like building out a new product from scratch or whether you are working on existing product is the most important thing to do.

And especially when you're building a product from scratch, you don't have those resources. Most people, at least , don't have those unlimited resources, right? So if you're truly listening, you can make sure A, that there's a market fit, right? Of maybe you hear from people that your idea, even though you think your idea is like the greatest thing ever, maybe there's not a market fit, right?

And then you save yourself this heartache of, hey, build this out. I spent all this engineering time and now I don't have our product. So, just again, like so important to just listen to your customers or prospects, right? Or potential customers, what they want, and also making sure there's actual viable business value.

So you're not just building out a product. Unless your model is freemium, right? But at least that you have a, there's a need and then also that people [00:22:00] would actually pay for it.

Roman: Yeah. I think that those are really good points. And what I would add is that number one, everything that I'm saying here is not too far off from what agile development tends to be.

Right? When you think about it in terms of iterative cycles and getting customer feedback, that's pretty much what I'm saying here as well. You really wanna go in and you want to iterate based on real world experimentation. I think a lot of people talk about agile, they talk about sprints and talk about cycles and talk about shipping at the end of the day.

The most important thing that you can do is, is to actually, actually do that, right? If you have sprints, that doesn't mean that you're agile, it just means that you are trying to work in two week blocks, or three week blocks or so. The most important part of agile development is to talk to people and to use that as guidance to refine the things that you are building.

The other thing, and I think that this is just a broader observation about the industry, is that, because building things tends [00:23:00] to be expensive that I, I think that that's why a lot of engineers end up starting companies, especially today. When you have that skillset, that's a cost center that you don't have to invest in right away.

And so you can start to build something out on your own and bring that to the market. Whereas if you are a product manager or you're a marketer, or you are a business executive that has an idea, then you have to either learn how to engineer something if you're in the software space, or you have to hire an engineering team.

And so it becomes that much more important for you to do that upfront research before you hire people on to build things. But likewise, if you're an engineer starting your own company, The same thing applies. It's so easy to get caught into a build trap where you say, well, it's not expensive for me because I know how to do this.

And then the next thing you know, you spent three months, six months kind of building a thing and, and refining the architecture and trying to make it perfect and squashing every single bug before you've actually shipped it to customers, before you [00:24:00] refined it. You built an entire roadmap of, you know, we're gonna have this first, and we're gonna have that second, we're gonna have that third.

And then you, you bring it out to the market and maybe people don't buy it. Maybe you you know, mistook what people said as, these are interesting things that they would want to use, but they don't have a budget for this, or this doesn't neatly fit into and the way that people acquire software.

Or maybe that's not how they solve the problem. I, I think one of the biggest things is also when you're talking to customers, a lot of people will give you feedback that's helpful. But there can often be a disconnect between when somebody says, oh, this would be awesome and I'd love to buy this, versus when people actually do open up their wallets and buy something.

So in, in addition, you're just listening to them. You have to listen with the critical ear and actually validate it against how they act as opposed to say they will act.

Kayla: So on the subject of listening. For our listeners, I would love for you to share one piece of advice to either, you can take this one of two ways.

You [00:25:00] could share a piece of advice to someone who's founding a company with a product perspective or just a piece of advice to an aspiring product leader.

Roman: That's a good question. I think that I'll try to give advice that applies to both or at least two pieces of advice.

On one hand, for people who are aspiring product leaders, I would say learn as much as you can and especially early on in your career, learn from other people. Take the opportunity to understand how different departments work. Learn how finance works, learn how engineering works and how they make decisions.

Learn how you interact with marketing and how sales works and how the decisions in those departments are driven, why they do the things they do. And the reason for this is because this will make you a better product manager and a better product leader. The further up the chain of management that you go, the more likely it is that you're working not just on technical expertise of how to write a good PRD or how to do good [00:26:00] customer research, or how to do analytics.

But you're really trying to figure out, you know, how do I fit into the broader view of an organization? Right? How, when I build something, how do I need to work with sales to get them to sell it? Or how do I need to work with marketing to get them to promote it, or how do I operationalize it and scale it for multiple users?

And then that advice, I think, is also helpful to anybody starting a company because, when you're starting out and you're creating it you're taking a leap of faith and you're essentially saying you're gonna do all of those things on your own. And so if you don't understand how marketing and sales works, if you don't understand how finances work, if you don't understand, you know, how engineering works, having a great idea is probably just the first step of your journey. Everybody has great ideas, right? Everybody has, you know, hundreds of ideas or opportunities that they think would be great to solve for. But it's really about the execution of that, that you need to think about. And if you're able to execute [00:27:00] it, then you're really gonna have to understand how all of these different pieces of a company come together to make a successful business.

So, no matter you know, who you are or how you're trying to grow, definitely take the opportunity to learn what drives other departments, how they make decisions, why they do the things they do. And if you decide to stay within product management you'll definitely be a better leader for that.

You'll understand how the . Things you do, where they fit in and, why they fit in the way they do. What pressures organizationally you have to help solve for. And if you do choose to eventually start your own company, well, you'll be armed with all that extra knowledge that'll get you two, three, or four steps ahead of everybody else, because you won't have to try to reinvent the financial wheel as, as an example.

Kayla: Awesome. And then where can people find you?

Roman: So right now I am on LinkedIn. I'm happy to connect with everybody. And then I also write at romandesign.co as well as errorstates.com.

Kayla: Awesome. Well, thanks for coming [00:28:00] on today.

Roman: Absolutely. Thank you so much. And it's been a pleasure.

Kayla: Thanks again to Roman for joining us on today's episode of Product Chats. If you want more product management resources, head to canny.io/blog and we'll see you next time.