In February 2023, I recorded a podcast with Kayla Cytron-Thaler at Canny.io about the role of product management, building products from scratch, and more. This is the video, audio, and cleaned up transcript.

In particular, the transcript is a bit different from the recording – I'm taking it as an opportunity to clean up my thoughts, remove some redundancy, add in detail where it was missing in the moment. Not substantially different, but not a direct transcript either.

Building a Product From Scratch with Roman Kudryashov of Recommended Systems

Roman Kudryashov is the founder of Recommended Systems and co-founder of Dragon Blood Balm . He started his career in journalism – right when the industry was trans…

Product Chats

Transcript

Kayla: Thanks for tuning in to Product Chats. On today's episode, I talk with Roman Kudryashov, who is the founder of Recommended Systems. We talk about building out a product team and also building a product from scratch.

In a minute or less, can you tell us a bit about yourself?

Roman: Sure. My name is Roman Kudryashov. I am currently the CEO of Recommended Systems and Dragon Blood Balm. Before I started those two companies, I was the 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 and as a Director of Digital Operations. I've had a chance to work in a number of different industries from software to physical products, from the luxury sector to healthcare.

The Non-Traditional Path to Product Management

Kayla: Let's actually dive into that a little bit about where you started and what that journey has kind of looked like, diving into how you got into product.

Roman: I think that my road to product, like many other people, was non-traditional. I don't think that—or at least five to ten years ago—there weren't any courses that you took in college that were explicitly about product management. I started my career in journalism, and that was when every single newsroom was going through a transition to digital where print publications were going out of style and everybody needed to have a web strategy, a digital strategy.

As part of that, I had to transition into learning about how digital products are created, what works, what doesn't, how people come in and interact with web properties and software properties that were being put out there. That led me somewhat directly into marketing, where I had the opportunity to think about even deeper how to acquire users, how to keep them engaged, and how to make useful things for them.

There's often two big areas that people tend to specialize in, when working in marketing. One is the traditional realm of marketing communications (advertising, communications, email strategies, media, and so on), and the other one is product marketing. With product marketing, you're thinking about how to build a relationship between the company or the product that you're creating and the consumer that is on the other end of it.

When you think about that sort of relationship, you find yourself in a cohort alongside a number of other departments that are also thinking deeply about that. Product management and product development being one of them. So in doing that work, I found that marketing (as I was doing it) was starting to deeply overlap with solving the problems that product teams were working on. So I had a chance to informally start working with them and then eventually I transitioned into a full-time product role where I was responsible for building out internal tools that were informed by our team's and company's needs, and when I was successful at at, to an explicit role building and leading a product management team.

Building Teams from Scratch

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

Roman: My experience has been mostly around 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.

The biggest question when you're starting something from scratch is: what is it that you're actually trying to accomplish? For example, when I come into a company, oftentimes the initial guidance that I'm given is more so in the form of a question or in the form of a challenge. Someone might say: "We have an opportunity of some sort and we think that product—or marketing, or product 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."

So when I come in, the first thing that I need to do is figure out: how does this department actually align with the business goals? Where does it fit in? What already exists, and who does that work? Whatever the answer is to those questions, that informs the team dynamics and expertise you need to bring in. For example, do you have a fully robust engineering team that you're partnering with, or are you relying on an agency? Do you have a community education team that can augment the things that you're building, or is it going to be the responsibility of the product team to own some of those communications?

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. There's never an out-of-the-box solution to pull from – I've always built teams in situational, contextual ways.

Another example: if you're in a more enterprise organization, it may be 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 deliver that. Your product team may need to lean into having project and client management skills. Whereas if you're in more of a direct-to-consumer space, you'll probably want a team that's more hands on with research methodologies, mass communications, and prototyping techniques.

And after you've figured that out, the most important thing is to show meaningful progress. You don't have an unlimited timeline for these things and you don't want to squander the trust you start with. That doesn't mean you have to make quick and rash decisions but you do need to figure out how to quickly get to action. I think that anybody coming in—whether you're at the manager level, at a director level, or 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 more trust and permission to try more things. And with that trust, your the team begins to grow – in every way (practically, psychologically, size-wise). Your capacity to take on additional challenges begins to grow as well.

Demonstrating Value in Different Contexts

Kayla: I kind of want to dive into how you actually hands-on demonstrate that value and what does that look like.

Roman: That answer is very context-specific. If I think about, let's say, in an enterprise organization, value may be around creating product utilization. For example, at Pager, we had a B2B2C model where we worked with payers and we indirectly helped our clients get patient utilization—we helped them get utilization through their membership. But the kicker is that it was a B2B2C model, so we didn't have control over the final utilization plans. We proposed ideas and models to the client, but the client had to implement it – we were a feature embedded in their bigger app. We couldn't follow a lot of "best practices" because we didn't own the end-to-end experience.

So as a product manager, one of the most important things for us was to figure out how to build a product that conforms to the ecosystem that our clients have and then within that, how to manage the relationship to the place where the client wants to follow – or at least is open – to our advice and strategies. Some of the ideas we got the client to implement had nothing to do with our product, but made the overall client app better, and as a result drove our own utilization up. We became a trusted consultative partner to our client, beyond simply being another vendor. That consultative relationship led to more and broader contracts beyond the feature set we had already built. That was the value being created, beyond any trackable metrics.

Whereas if you are a direct-to-consumer company, you probably have way more control over your product and as a product team, you may be more focused on traditional business metrics. For example, what do your referral rates look like? What does your utilization funnel look like? What do your returning users look like? And then moving the need on that. It's much easier to measure, but just as valuable.

In that sense, product management is extremely deeply intertwined with the business model and the monetization strategy. It's not about making and launching features, though that might be what the work mostly looks like. It's about the target that the work is pointed at, and the target is a business target.

The Unique Role of Product Management

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. I've seen a lot of successful product teams giving their teams the 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 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: Right, 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—one of the things that I see broadly in the industry—is that it's very easy for product management to get caught up in the software development cycle. You see articles on Medium or on personal blogs that are talking about the successful delivery of features: "We shipped something in a timeline and it had no bugs." And that's wonderful, right? As a company, we all want to be able to ship software that has no bugs, software that gets used and hopefully delights the customer.

But when you think about the role of different departments in a company, there's a trifecta in that world. On one leg you have product management, on another leg you have design, and on a third leg you have engineering.

When you think about it in that sense, what is the unique thing that product management brings to the table? When you think about the successful shipping of features without defects, that's really a question for engineering. Has the engineering team built things that are reliable and that work?

And likewise, the questions around "Are people using it? Is the experience that is being created well?" is really the domain of designers to come in and think through. They're the ones that should be asking, "What are 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?"

Okay, well then what does product management do? Product management answers the question of, "What are the important business questions for us to tackle?" As an example, when you write a PRD, the thing that you are trying to solve for or answer is: if we solve this problem, will we be able to create business value?

Then you begin to define the KPIs around that. "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." 'Product' metrics and 'business' metrics often overlap, but not always. Same thing with 'marketing' metrics and 'business' metrics. It's really easy to get lazy about that and use them interchangeably, and then when you get product managers talking about the number of clicks and page views or marketing people talking about the number of impressions, and the business folks in the room get frustrated because they can't draw the line back to the world they're operating in, which is often financial metrics. Almost everything gets translated into financial metrics at some point, because that's what businesses are organized around. And that's not a judgement call – there are other organizations (such as governments, NGOs, non-profits) – that are organized around other value metrics. But the purpose of a business is to survive and thrive, and that's a function of making money.

Then in addition to that, product managers also need to solve for the promise of taking on work. You've promised to take on some work, and gave a convincing reason for taking on that work. How do you make sure that work actually delivers on that promise? Because very often if you've built a really fantastic feature and you've shipped it and but nobody's using it, then you've not actually gotten value that you promised.

So it's not the work that's important, it's the results of the work. That's both terrifying and liberating. The terrifying bit is that you have a lot of advice out there that talks about prioritizing process over outcomes, and this sounds like I'm saying the oppositel; process is great, and good processes are more likely to consistently get you to outcomes, so I'm very much for good processes. But if you're judged on outcomes and not processes, that can get scary. But the liberating thing is that if you're judged on outcomes, everything before that outcome is flexible. Any problem can be solved in multiple ways. Say that you're tasking with "drive utilization". You can do that through a new feature deployment. You can do that through a marketing or communications campaign. You can do a webinar. You can talk directly to hundreds of customers. You can A/B test some interfaces and microcopy. You can come up with 15 other strategies for driving that outcome. You goal isn't to stay fixated on one way of working, so get creative. Some tactics are cheaper or more expensive, easier or harder. Choose your own adventure on that.

So to sum it up, what product management brings to the table is this explicit business focus. It's not project management, it's not about trying to be a scrum master or product owner, it's not managing the software development lifecycle—it's solving explicitly defined business problems. And that's where the creativity, that's where the logic, that's where the analysis in product management comes from.

I'm really digging deep into this because there are plenty of times where the solution to a problem 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 communications campaign, or to equip salespeople with content. Too many product managers only reach for the "build more software" toolkit.

This is important to remember because engineering resources are expensive. It requires a lot of people to build and run enterprise software, it requires a lot of people to build scalable things, and so you want to make sure that when that team is working on these projects, they're not wasting their time. They have limited time, so you want your partners to be spending that limited time on the most important things.

As so part of that, you're trying to figure out: "What are the right problems? And how do I solve those problems in the most efficient way?"

And then explicitly and intentionally, if the solution is a software solution, you're letting the designers and the engineers be participants in the 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. You don't want to turn designers into pixel-pushers or engineers into typists. They have a lot of perspective and experience to bring to the table, likely more than you do in the areas that they work on.

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.

Getting Close to Customers

Kayla: You bring up a great point about not wasting engineering time because it's really expensive. I think that goes into something that's really important as a product manager or even as a product leader—actually getting in the weeds with your customers and actually sitting down and understanding them: 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 out A, B, C, D."

I know in some cases—you mentioned 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." That's a huge role of product: 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. It could be a different landing page or it could be something else, and it's not always "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 you're not 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're 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 so the idea of who is even a "customer" doesn't match up perfectly.

But the customers are the ones that validate the purpose for your business's existence. Customers are existential. You have to figure out who they are, who makes buying decisions, what drives them to make those decisions. It's an existential question.

And not only that, you have to find ways to translate the problems and ideas that people are coming to you with, to how you might be able to begin solving it. That translation layer is extremely important because more often than not, people are actually coming to you with solutions-that-look-like-problems, and not the root problems.

When they come to you with solutions, they do two things. Number one is that they make a ton of assumptions about what already exists and what's possible, what's reasonable. And those solutions might be extremely costly, they might be extremely difficult, they might not even solve the right problem if somebody hasn't done a root cause analysis and said, "Well, what is this actually a solution to, 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. But if you think deeper about the problem, it turns their perceived problem is actually a symptom of a larger problem.

So you have to go through a process of asking "why" multiple times. "Why is the fact that 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 people to use it?" "Because we think that there might be certain results that you get from that."

Every time you go and you ask "why," it opens up the problem space more and more, and that opens up the variety of solutions that test out. That both gives you more flexibility, and makes sure you're actually solving the right thing.

The other thing about that conversation is, again, a lot of people think in terms of solutions. And I fall into this trap as well, because it's extremely easy to do this. People coming into the product space have a lot of taste, right? 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 everyone has had this experience, everyone has used apps and has ideas of what software should look like. Your taste is a useful input, but it's not what makes you an effective product manager. It's not even a core skill, because anyone can bring that to the table. If all you're doing is relying on taste, you're not doing your job. You can probably rationalize what your taste-led suggestion is the right one, but you don't want to be in the business of rationalization and pitting one opinion against another. But I'm getting a bit off track – the point is, good ideas are not siloed within the product management space. Anybody can come to the table with a good idea or a good solution.

So as a product manager, you want to stay focused on the problem and not on the solution. You need to be able to step back and evaluate multiple possible solutions, and experiment with different solutions. Your job is to make sure that the problem-solution matchup works, and you want to have all the solutions, everyone's ideas on the table for that.

Building a Product from Scratch

Kayla: On that piece about getting 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: Building a product from scratch is tough! A lot of times when you come into a company, there's something that already exists, right? Whereas when you're building something that has never existed, then on one hand it's an extremely exciting opportunity—you can solve anything, you can create anything—but at the same time, going back to that previous point that engineering time is expensive, so whatever you choose to work on, you need to make sure that you're doing something valuable.

So the decisions that you're making are – more than any other time – explicitely about the business outcomes. When you're starting a new company, you have a limited amount of time, you have a limited budget or runway, and you have a very limited number of people. So you can't afford to spend a lot of time 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 what problems they're willing to pay you to solve and what they're willing to live with (and are ambivalent about).

Again, going back to the idea that a landing page can be more effective than an actual product solution, this is where you want to try things that might not scale or aren't optimize just to test the waters and validate your ideas.

For example, if you're building a chatbot, you may want to start by not having a chatbot 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 behind the scenes. You don't want to be in the business of building solutions in search of a problem.

A lot of people get started, especially when they're trying to start something new, by having an idea and having this rough opportunity in mind, and that's awesome—that's what gives you the initial direction. But once you have that, the most important thing to do is to actually talk to potential customers and see how they use it, if they're willing to pay for it, if they're providing any sort of feedback, if their behaviors are very much in line with what you expected before you invest in the time to optimize for that.

Because once you optimize your solution, you're essentially locked it in. It gets more and more expensive to change features that are already built. Tech debt accumulates. And especially when you're building something new, this sort of feedback and guidance that you're going to get with your first 10 users or with your first hundred users is going to be extremely different as your next thousand users come on or your next 10,000 users, and then again as your first million users come on. The challenges and the architectures that you're going to have are going to be totally different. A product for your first 10 people is a functionally different product, a different company, compared to a product for the next 10,000.

So the most important thing 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 behaviors. It's no different when you're starting a company, except that the stakes are much higher and there's no prior thinking/validation for you to rely on.

The Importance of Customer Validation

Kayla: Just to echo your point about listening to your customers—at the end of the day, whether you're building out a new product from scratch or whether you're working on an existing product, it's 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. So if you're truly listening, you can make sure that there's a market fit. Maybe you hear from people that your idea, even though you think your idea is the greatest thing ever, maybe there's not a market fit, and then you save yourself this heartache of "Hey, I built this out, I spent all this engineering time, and now I don't have a product."

So again, just so important to listen to your customers or prospects 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—but at least that you have that there's a need and then also that people would actually pay for it.

Roman: Yeah, those are really good points. 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 want to go in and you want to iterate based on real-world experimentation and learning.

I think a lot of people talk about agile, they talk about sprints and talk about cycles and talk about shipping. But 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. It's to build a loop of learning and acting, learning and acting. If you just make a loop of acting (traditional sprint planning), you're missing the point.

The other thing—and I think that this is just a broader observation about the industry—is that because "building things" tends to be expensive, that's why a lot of engineers end up starting companies, especially today when you have that skill set. 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're a product manager or you're a marketer or you're 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 spend three months, six months building a thing and refining the architecture, trying to make it perfect and squashing every single bug before you've actually shipped it to customers. You've built an entire roadmap of "We're gonna have this version, we're gonna have that second, we're gonna have that third." And then you bring it out to the market and maybe people don't buy it. Maybe you 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 the way that people acquire software, or maybe that's not how they solve the problem. Oops, you've spent all this time building the wrong thing and you can't get that time back.

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 addition to just listening to them, you have to listen with a critical ear and actually validate it against how they act, as opposed to what they say they will do.

Advice for Aspiring Product Leaders and Founders

Kayla: On the subject of listening, for our listeners, I would love for you to share one piece of advice. You can take this one of two ways: You 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 maybe 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 decisions in those departments are driven—why they do the things they do.

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 you're working on the same business problems they are working on but just applying a different solution space to the problem. Product, sales, marketing, etc, they're all working on business problems at the end of the day, but applying different toolkits, tackling different parts of the problem. So after a while, you're working not just on technical expertise of how to write a good PRD or how to do good customer research or how to do analytics, but you're really trying to figure out: How do I fit into the broader view of an organization? When you build something, how do you need to work with sales to get them to sell it, or how do you need to work with marketing to get them to promote it, or how do you operationalize it and scale it for multiple users with engineering?

And then I think that advice is also helpful to anybody starting a company, because when you're starting out, you're taking responsibility for all of those departments. So if you don't understand how marketing and sales works, if you don't understand how finance works, if you don't understand how engineering works, having a great idea is barely getting you to the starting line. Everybody has great ideas. Everybody has hundreds of ideas or opportunities that they think would be great to solve for, but it's really about the validation and subsequent execution that makes a difference.

And to execute, you're really going to have to understand how all of these different pieces of a company come together to make a successful business. Not just a feature or product, but actual sustainable business. An idea isn't a business, a product isn't a business.

So no matter who you are or how you're trying to grow, definitely take the time to learn what drives other departments, how they make decisions, what they do and how they do it and why they do those things. If you decide to stay within product management, you'll be a better leader for it. You'll understand how the things you do fit in with other skills sets in your company, and 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 and skills that'll get you two, three, or four steps ahead of everybody else.

Kayla: Thank you, Roman!