Product 101 for Techies and Tech Teams with Amanda Savluchinske

Uh so hi everyone, I'm Amanda Savluczynski and today we're gonna be having a product talk. And uh this talk's intention is to be a crush course on product management. So please think about it as a product starter kit for tech people. And before we start, I'd just like to introduce myself really quickly. I'm a PM at Vinta Software, which is a software boutique located in Brazil, although we mostly uh work with clients based in the US. And one fact about myself is that I haven't always been a product manager. I actually uh started out as a developer myself and really value my technical background And having lived the best and the worst of both worlds, I find it extremely important that developers, designers, and PMs alike are all able to speak the same language, at least on a basic level.

So before we even start, uh I'd like to give some disclaimers. Uh here's the thing. Uh I've given some talks before and it doesn't get any easier. I'm always pretty nervous. So I just want to get some facts out before we start so everybody's on the same page. So, first, all experiences are my own. Uh and yes, I'm bringing some literature here, but a lot of this talk comes from my own personal experience and what we do at Vinta. Second, I perform a project manager plus product manager role, so your mileage may vary. And third, I work for a software boutique that works with various product companies. So The experience a PM gets managing a single product directly may be different. Alright, so the talk is divided into two parts. And the first one is about becoming more product-minded.

While the second one is the hard skill part of the talk, uh which will allow us to dive a little deeper into the product domain. And within that product domain, uh, we're gonna have A, understanding the strategy, in which we're gonna cover things like the product lifecycle, strategy and vision. Goals and roadmaps. And we're going to have the B part of the talk, which will be covering things like personas and customer journey mapping, product discovery, delivery, and also product metrics. And there's also a cheat sheet that you can check it out. So, like if you like to scan this QR code, there are some terms that I'm gonna be using in the talk that it might be useful to have a little help. I'm gonna leave it there for like uh five seconds.

All right, I guess you guys got it. Okay, so now let's get to the real deal, starting with how you can become more product-minded. As a starting point, I'd like to cover some traits that most PMs expect from their technical colleagues. There are all types of PMs, like technical ones, hands-on ones, hands-off ones. But in my opinion, if software development was an online game, the managers uh would definitely be support characters Because the manager's job is not to do their team members' jobs for them, nor is it to be the main character. The manager's job is to, one, make good decisions about the product strategy based on the input they get from their own work and also uh other experts. So should I save that heel for later? Um second, empower everybody on the team to deliver their best work.

So buff everybody up. And third, perform their own work like defining, pulling, and analyzing metrics, uh running product discoveries, uh, research tests, and so on. So that would be their tax skills. Speaking in practical terms, here are the top three things your PM wants generally. So a team that is interested in the strategy so that they can make microdecisions about the product development. Genuine interest in solving problems, so curiosity, and also empathy with end users. And this is a shared responsibility between the team and the manager, so let's go over it in two parts, starting with the PMs. So, PMs need to empower their team so that they are aware of product strategy. And the team also needs to understand what they're building, to whom, and why

very clearly to be able to translate that into actionables. PMs should present strategy clearly to their team and keep them updated on changes because the strategy is bound to change. And I wouldn't like to go into a lot of detail of what that means in practical terms because there are endless ways of applying of applying these concepts. But this is the gist of it. And I actually wrote a blog post about project visibility last year, uh which contains some of my thoughts on the matter, so you can check it out in this QR code too And the team mainly mainly needs to worry about their curiosity. So like you don't need to know everything. It's not your job to be a product expert. This is what product managers are for. What you do need is to be interested in solving problems and to have empathy with the people who are gonna use what you're building.

Another important trait is attention to detail and quality. And this may sound a little abstract, but I believe it's what best sums it up. We want you to care about the experience from start to finish. So in practical terms, that means if you own a task, you really own it, from planning it to discussing implementation details, implementing it, shipping it, testing it, measuring its success, and so on. In summary, there's a certain engineer profile that the best tech teams usually have, and that is the product-minded engineer. And we're gonna go over that in a second. Of course, these are all generalizations and no one can really answer what your PM wants but themselves. Um it's always a good idea to set up a one-on-one from time to time to understand what these are, even if you think you have it pretty clear I think it's always better to over-communicate and adjust that communication than under-communicate.

Alright, uh so expectations on both sides are now clear, but how do we bridge the gap? I have witnessed how hard it can get for some PMs to communicate with developers and vice versa. And in an ideal world, every character in the story would be interested in understanding a little bit about their colleagues' world. not to actually become an expert in that field themselves, but to get the bigger picture and clearly communicate about challenges and opportunities. This won't always apply to the real world though, so let's just get to the part that you can control, which is your own approach to this. And the first step here is to understand your audience, like how technical is your PM? If they're somewhat technical, you may not need to go into a lot of detail about like the nuts and bolts of what you're trying to do. But like if they're not technical at all, you need to be actively mindful of your own communication.

Um and like one of the worst things that I think can happen in a PM dev dynamic Is when the PM just gives up on understanding the practical details of what their team is doing. Because like this just ends up generating more work for everybody involved because more people need to be pulled into things like discussions and alignments. And after you made sure that your audience gets you and like uh you get your audience to, the next challenge is understanding a little what of what they know best. Going back to that whole product-minded engineer concept, uh, to become one, you first need to understand whether you see yourself in this position or not. And it's okay that not all engineers may want to be product-minded engineers. Like companies generally have room for everybody, from the most technical to the most business inclined.

And people are allowed to have different uh inclinations and simply not like a certain career style, right? The downside here is that you might not be the top choice for delivering uh valuable product insights in your own work when building features. And depending on your situation, this could affect your career growth. Uh there may also be a case in which you'll have no choice but to become product-minded. For example, like startups with no PMs. It's not a rare occurrence and many times like CEOs or whoever's uh in charge may be biased in their product decisions. Uh so having a product-minded person in the team in this case is a must. In any case, it's good to try it before you make up your mind So let's go a little bit back uh to those traits that PMs expect from their tech counterparts.

Uh for instance, a first step would be to take interest in the business and its user base, right? So for starters, when understanding what your user base needs, a problem-first approach is very important, especially when it comes to empathizing with them and solving real problems. It's very easy to fall into the trap of like interviewing users and going with the solutions they offer. So you need to be very intentional about filtering the solution talk out and turning the discussion around to cover the problem itself And we're gonna cover that later in the talk when we go over things like personas, the customer journey maps, and also user interviews. Understanding the strategy and connecting the high-level goals with actions you can take as a developer also plays a huge also play a huge

part in this step as it'll make you more autonomous. By clearly understanding the main objectives, you need less input from others when making microdecisions in your workflow. So this is also something that we're gonna cover in the strategy section of the talk. Uh the second step here would be to stay curious, like we already mentioned, and this curiosity will help you gather unspoken context about the problems you solve. And it'll also help you be opinionated about better solutions as you have the knowledge to propose alternatives. And the best engineers I've ever worked with generally fit this profile And they usually come up with the most creative solutions, sometimes even cheaper than what we considered before. And this profile also tends to spark up healthy debates, which in turn contribute to great to

building great products The third step here is to provide relevant input. So as an engineer, you're the person with the most context about the technical side of the product. So it's crucial that you're vocal about constraints, implementation details, and alternatives. And of course, uh PMs and designers will usually try to prioritize the most user-friendly solution, but there may be cases in which there's a second best choice there. that is way cheaper and more often than not the cheap second best is the one to be chosen. And the fourth is to be an ally to your PM if you have one, because by being an ally to your product manager You'll increase the chances of driving your product to success as you'll be constantly providing your tech input to them as well as receiving valuable context about the business that can influence how you and also your team approach feature building

And you can also leverage this relationship to learn more about product-related concerns and become an even better product-minded engineer. We're now going to move on to the second part of the talk. As for this first part, you can learn more about becoming a product mine and engineer in these links. They were very helpful to me when building the talk, so you should check them out for more insights. Alright, so let's get into the hard skill part of the talk now, which is the crash course on product product-related subjects. And These are a mix and match of product content, project management, and business in general. So bear with me if you have heard about some of them before, because the idea here is to cover as many basic subjects as possible. And we're gonna start with A, understanding the strategy. Starting with the product life cycle, like

the main thing here is that there are four phases in which every product in the market may cycle through. And these are introduction, growth, maturity, and decline. Sometimes the product may only get to the first and like jump directly to the fourth phase. Sometimes it goes through every one of them. And the idea here is to go into detail about each phase and understand why it's important to capture in which phase your product is situated. Let's talk about the introduction phase. Like this is the phase in which the product first hits the market. So like you can introduce this product in many ways, right? So through demos, social media, one-on-one presentations, and more And the key here is to make sure that we're solving the right problem and moving toward a product market fit. It's also important to stay curious and flexible

because sometimes a small pivot can help you reach a bigger audience And while also avoiding the sunk cost fallacy, which means like you know continuing with an idea just because you already invested a lot of time or money into it. And there are a couple of things that you can do as a developer to help your PM in this phase. So, like first, ask questions, try to understand why you're implementing something and what we would like to prove by doing it. And also think about strategy weekly. So ask your PM questions about the company's goals and provoke them into suggesting ways that you can support this growth. Talking about growth, so like this is a stage that is crucial to a company because in the introduction phase you may have validated that your idea works for a select group of people. or companies, but in the growth stage you want to scale and make sure you cross the chasm of adoption.

And this is a phase in which profit margins will increase if everything goes well. A few tips for this phase is to like encourage experimentation. So like propose new ideas based on what you already know of the strategy. And also has to be included in product discovery calls with end users because this will help you gain empathy about what their problems are and give you new ideas on how to solve them. The maturity stage indicates that the product has reached its highest profitability, and usually companies that anticipate they will enter the decline stage soon. Uh use this moment to try and innovate. They may acquire smaller companies with groundbreaking ideas, build innovation hubs uh inside their companies, or simply do nothing at all to prevent the decline.

And things you can do in this phase include things like uh keep an eye out for market trends, suggest ways to keep to refresh or add features to keep the product relevant. And also collaborate with the PM to identify potential areas for innovation and improvement. Lastly, indicators of the decline stage are decreases in sales Loss of market share and failed efforts in marketing. And if a company hasn't used some time in the maturity stage to find other sources of revenue, this is probably their last shot at succeeding before their current source runs out And how can you help your PM in this phase? Like be proactive in exploring new revenue streams or partnerships that could potentially revive the product and also maintain open communication with the PM to assess the situation and also strategize accordingly.

Now, let's talk a little bit about strategy and goals because by understanding where a business stands in terms of the product lifecycle, we can now start to think about strategies that connect to that moment. Before we start, I just want to leave a visual cue about the following subjects. It's a funnel with uh mission and vision on top, followed by strat by strategy. goals and then roadmaps. And it serves to illustrate that we're going to be talking about broader strategy and then funneling down into more specific plans. Uh there are several ways to approach a company's strategy, and each one plays a crucial role in defining its direction and long-term success. To begin, I'd like to focus on the importance of mission and vision statements as they serve as the foundation for guiding a company's goals, culture, and overall strategic decisions.

So, for the mission statement, like this statement usually describes the business of the organization, uh, its goals, and also strategies uh for achieving those goals. This focus normally remains unchanged over time and it answers questions to like why the organization exists and what it aims to achieve. And this statement must be very clear and to the point, providing a sense of direction and also guiding decision making within the organization. So for GitLab, for instance, their mission is to make it so that everyone can contribute. As for the vision statement, this is usually like a long-term goal that describes the future aims of the organization. So it's usually more aspirational with the goal to like motivate and uh unite employees toward a common future objective.

So for GitLab, their vision is to become the all-ops platform, a single application for all research and development. And while uh you won't be responsible for setting these up, as long as your company's mission and vision are clear to you you'll be better equipped as a developer uh to make strategic decisions and you know just do good choices overall. Um This may seem very high level and you may wonder how that could connect to your day-to-day work, especially if you work on something very technical. But You'd be surprised uh how much that can influence your decisions. Having been a developer myself, paying attention to the company's objectives at a higher level made me grow at a faster rate in my career than if I had stuck uh to my daily work without ever considering the strategy.

And the consequence of you knowing the strategy by heart is that you'll be extremely aligned with what your company wants to achieve and will make better decisions in your domain. So how can you do that? Pay attention to strategy meetings if you have them. They may seem boring at times. They sometimes take time. You could be using to like code or review PRs But they hold valuable information, sometimes even somewhat concealed information, that if you pay close attention, can help you grow in your career. Also, ask questions, like don't be afraid to ask about things that may seem like none of your business, because leaders will usually pay attention to that and be happy that you're interested in helping them, and that will be a positive for you. Also, keep in mind that some of these statements will change as changes within the organization and the environment happen.

So it's always good to keep up with whatever news you can find about the strategy. Uh moving on to like strategic plans. Like this is basically the actionable part that derives from the mission and vision. And it brings these ideas to a practical format, like result resulting in this plan. Consisting of like a few concrete statements that will hopefully get you closer to the ultimate goal. It's better to be more specific than general when it comes to strategy, as it's hard to focus on multiple areas at once, and we're gonna see an example of that next. This example is from a Lenny's newsletter article. It's one of the newsletters I'm going to recommend at the end of the talk. And it's a strategy of Yahoo's And it's from a memo uh their VP released in 2006 that became known as the Peanut

Butter Manifesto, in which they pointed out Yahoo's lack of focus and specialization. And they called it peanut butter because their previous strategy was spread out as opposed to sculpted. And what Yahoo did there was to understand and acknowledge its problems. figure out where they wanted to go and finally plot out a strat a strategic plan to resolve the issues found. Each one of the these items have like had like several sub-items on how they were going to address those challenges. For example, in the first one, Focus of Vision, they stated that they needed to get rid of like non-core businesses. And from that statement, leaders could then think about more practical plans to sunset these non-essential projects. Plans that could include things like details on timelines, which businesses were non-core, communication plans, and so on.

So as an engineer, you can definitely extract tactical and operational plans from a plan like that too. From the mission and vision statements as well as the strategy, we can start talking about high-level goals. Some companies set these goals in different ways. They may use like OKRs, which are objective key results. They may use SMARC, which stands for like uh measure specific, measurable, achievable, relevant, and time-bound, uh, a balanced scorecard or something else altogether. And these goals are especially useful for turning the strategy into measurable results. By breaking up this strategy uh into smaller pieces, organizations can divide and conquer with their teams working on separate bits that will eventually lead to a bigger goal being reached. And by staying connected and committed

committed to these goals, uh engineers are able to drive the organization toward their business priorities. benefit from greater engagement and motivation and also think more creatively on how to solve for certain user and business needs. So it's a win-win all around. As for my personal experience, I feel like OKRs can work great in some cases, but they may not be a fit for all teams though. Like I've worked in instances where like we used KPIs because our goals were more stable and I keep doing uh bases. On teams that use like high-level strategy plus other methodologies like squad health checks. The idea here is that there are different ways to set goals and there's no recipe for success when it comes to frameworks. So you should do what works for you and your team. So

getting into roadmaps. Roadmaps are ways to translate our goals and strategies into features and functionalities that we believe will contribute to achieving them. And they are great communication tools to get everyone on the same page about where we're at and where we want to go. They also help us prioritize and think about allocation. And this doesn't mean that roadmaps can change. In fact, it's very healthy that they do. As there are many variables that can influence a company's direction. And for that reason, it's important that the roadmap is periodically reviewed and updated. In summary, they're basically prioritized lists of functionalities and projects. Some argue for not having roadmaps at all. And the argument is that there are two main needs that we're looking to solve when we propose roadmaps as a solution.

The first one is that everyone is working on higher priority items first And the second one is to guarantee that any promises that have been made to customers are reflected in the planning. In Inspired, for example, uh Marty Kagan argues that roadmaps are usually not a good idea. Because stakeholders take these roadmap promises to heart instead of treating them like ideas that can change over time. And he also argues that roadmaps are very much about deliveries instead of results. And fair enough, there are some alternatives to roadmaps. For example, if you have enough smart, experienced, and focused people, you can probably get away with setting goals per team and then letting them figure out the rest. This, however, requires a level of maturity that not all teams have the privilege of having. So one thing that he also mentions is that like as long as roadmaps

uh are lists of prioritized ideas There's not a lot of there's not a lot of downsides to it. So as long as stakeholders don't interpret these ideas as promises, you're probably fine. There are also things like the now next later roadmaps, which are pretty self-explanatory, result -based roadmaps, which have business problems as their items instead of like specific features and many others Most of my experiences with were with uh quarter-based roadmaps in which we would keep on constantly reviewing our ideas. And this ensured that whatever we were agreeing to tackle was in line with our objectives and strategy for the quarter. And whenever possible, we also involved the team to guarantee everyone uh felt connected to the strategy and could contribute to the solution I've also had experience with results-based roadmaps

in which we took like our high-level goals and connected them to features that we believed would would unlock the results we needed, but there are many more. Basically, there are countless ways you can choose to organize priorities. Alright, so now that we covered all of the strategy funnel, I'd like us to move up to move from part A to part B. So we're gonna stop talking about strategy and go a little more hands-on into how we understand our users and also validate our ideas. And I'm just gonna take some water. All right. Um so your company has a defined strategy. What now? We covered roadmaps, goals, and so on, but like how does that translate into actionable? How do we define what we're going to build to whom?

What problems we're going to solve? How do we deliver? And how do we measure whether what we're doing actually works? Let's start this out by talking about personas and how we can map their journey in our products. In turn, we're going to have a better understanding of how to aggregate value through our deliveries and Also be able to prioritize our roadmap uh with more than just hunches about what our customers want. So let's start with like water personas. Um personas are basically fictional representations of a target audience And they are defined based on research and data from real people who use the product. They are stereotypes of these individuals with their characteristics, behaviors, needs, goals, and preferences. And they help us map out who are our main types of users and to better empathize with their struggles and needs.

So some helpful data that we should have about our personas include things like name, description, demographics, customer needs. uh motivations, pain points, and also their journey through your customer cycle. And here's an example I took from a hubs article that pretty much showcases what this should look like. So We have Sarah and she's a young professional working in the financial sector. And she wants to save money and she wants a company to help her to invest that money. We also have her demographics there, but let's um you know skip that. So uh she has some needs, right? She wants to save money and receive investment advice, uh, and she wants to be financially secure enough to retire early. But like she often Worries that she's not saving enough money and she's also confused about how to invest it.

So maybe a journey for her uh within our product would be well, she's just starting her research online. She found our platform, we get her as a free user, and eventually we convert her convert her uh to a paid user. So like these are all conclusions that one can arrive at from a persona's research. that help us better discuss how our features may impact certain types of people. And it's important that everyone in the team is well acquainted with their products personas so conversations are aligned and we reach sensible conclusions about what really matters to their user base. In the projects that I use personas in, they were a great way to discuss uh the wants and needs of every type of user. For one of them, for example, we had admin users and regular users, and their journeys in the app were vastly different.

So having their details mapped out was especially helpful in onboarding, for example. Another example was a system in the health domain And in this area, uh there are many different types of users, like you know, providers, billers, clients themselves, and many others. So not having personas would make it super hard for the team to consider all users that can be uh can can be affected. when a new feature uh is planned, as well as understand like crucial data about them that will guide important product and implementation decisions. Another instrument to improve end user empathy and help us prioritize the right problems are customer journey maps. And they kind of build on top of personas, so that's why I'm bringing them up right after. It's a good practice to keep user journey maps tied to one persona with one task and one goal

because if we're too broad, we're gonna fail to gather insights about specific actions and goals and won't get the same results in the end So considering that Sarah example, let's explore a customer journey for an investment advice platform in which you pay like a subscription fee for consultancy services in that area. And sorry about the nearly unreadable image. The customer journey there is mostly to exemplify what I'm trying to say here. So I'll go over the most important bits. For example, in this customer journey, our user Sarah is going to pass through five phases, right? So awareness, consideration, acquisition, service, and loyalty. And we're going to analyze things like her user actions, goals and experiences, feelings and thoughts, pain points and opportunities along the way.

Actions she may take in this journey include things like searching for beginner investment guides and budget tools, comparing our platform with other platforms. signing up for a free trial, uh using our platform to track savings and investments until finally upgrading to a premium plan and recommending the platform to friends and or or colleagues. And we then map the remaining roles, like what she thinks in each one of these phases, pain points that she may feel, and also opportunities that we can take based on based on the information we have about the journey. For one of the projects that I worked for, we sat down with uh with a client and built a user journey map together, and it was especially useful because it was a very innovative idea. And we wanted to make sure that investors got what our user struggles were and how the journey in our platform uh would help them solve their problems.

This tool was also especially useful for onboarding uh because it helped new developers uh understand the main flow of sorry, main flow of the system before they even got to play with it. So uh they could also understand the motivations behind behind what we had built. Finally, this is just like a great instrument all around to get yourself into your users' shoes and guide your decision process based on their needs and struggles. So it can be a real eye-opener for opportunities. Moving on to product discovery and interviews. So product discovery is a brainstorming and planning phase that happens before creating something. So it's about finding out what competitors are uh what competitors are doing out there, what customers want to need, and also figuring out the best way to create something that people will value.

In this phase, uh, we try to understand more about the problem uh that we believe we can solve before actually committing to it. It's pretty safe to say that half of our ideas will not work out So product discovery ends up increasing the chances that we get it right as we're making informed decisions about what we're going to build. And it's also a great way of separating good ideas from bad at the end of the day. So, in the discovery phase, uh product engineering and design work together to answer four main questions. So, first, will users buy or use this, which is the value risk? Second, will users understand how to use it, which is the use usability risk? Can our engineers build this? Visibility risk, and will our stakeholders support this? Business viability risk

And after answering these questions, we should have a validated idea that is a little further down the implementation process. Does every idea need to go through product discovery? Uh no. For things that the team is fairly confident about Things that they have done before, and so on. Um you probably won't need to go through all of the steps here, uh, but discovery is a great tool for when the confidence in the solution, considering the four quite the four questions above, is low And this is a huge topic, so it would be very hard to cover everything in little time because it involves things like interviews, tests Customer journey mapping, which we already covered, story mapping, and so on. So I'd like to go over interviews and tests, and then we can wrap it up with delivery and metrics.

So, user interviews and product discovery are chats with potential customers in which you ask them about their experiences, needs, and frustrations to understand uh how they currently solve their problems or meet their needs. And these interviews help you gather valuable insights that guide the development of products that will help users. So it's all about listening carefully, asking the right questions, and uncovering the information that will model your product or or features. And interviews serve as a great way of validating if we really know our customers, like the problems that we think they have, how they currently solve their problems, and what it would take for them to adopt our solutions. It's important that these interviews have a clear purpose, so it's good practice to think beforehand about which questions you want answered

or which assumptions that you would like to validate with them. And it's also interesting to bring different perspectives into the meeting. So a good way of doing that is by involving designers and developers because Each one of them will interpret the information from their own point of view and will feel more connected to the decision process. So if your company does these types of interviews, has to be involved. Continuing on the discovery process, uh, discovery tests are essential steps in product development because they help teams understand different aspects of a potential product or feature. And also mitigate risks. And there are various tests that you can perform in this phase, but I'd like to focus on four that address the questions that we want to answer during discovery.

So testing the value of a product is crucial for making sure it's worthwhile. And that's why the first risk to be mitigated should be this one. As like if there's no value in building something, the rest of the risks don't really matter. There are different examples of value testing, like the Fake Door method, A-B tests, invite-only tests, and so on. I'm gonna be exemplifying some of them. So for the Ficdoor method, for instance, uh to validate interest, you can do things like pretending a fit feature exists and see if people click on it or sign up for it. So let's say that you have an internet banking product and would like to assess whether your user base would be interested in an investment product. You could risk it and build this investment product and then test it in the real world, but the stakes are high, right?

Like you could lose a lot of money Instead, you could just add a link to that investment product and inform users that the feature may be coming soon, but isn't available yet And you can also use the click data to assess whether people would be interested in that and even go further and ask people to share their emails or click a button to stay tuned to updates. Um A-B test uh consists in showing two different versions of a certain flow to different people. So when we're testing the viability of an improvement to an existing flow, this is usually done by taking like a large part of the user base. and keeping them on the current version while taking a smaller part and sending them to the new one. This can also be done before a feature is is launched and we'd like to assess which is the most effective version

Or like even with a product, like like you wanna you wanna test like different versions of like uh an ad, for instance. Lastly, invite-only tests can be done by selecting a few users and inviting them to test new features out or like you know new versions of your product. And since you're informing them that it's an experimental version and they can opt in if they'd like to, it's not a very risky move to test things out this way. But by choosing this method, we generally end up with a crowd of early adopters whose opinions and behaviors may not necessarily reflect those of a broader audience. Alright, so moving on to usability tests. These are all about making sure that your product is easy to use. So you can create

hi -fi prototypes of your product and watch how people interact with them. As this helps you see if people can figure out how to use their product without getting frustrated. And if they do get stuck, you can figure out how to make it better pretty easily because you'll have all that data to back you up And there are two types of usability tests. There's like the guided one and the autonomous one. And in the guided one, a facilitator provides direction and interacts with the participant during the session. As for the autonomous one, the participant navigates independently without any guidance. And I have a few tips for when executing guided ones. So Try to find people to test with on different channels. Like you can try testing your prototype with a few beta customers, for instance, or you can hire people externally to perform the test, or like even go to a physical place where people who would be interested in your product hang out.

So there are lots of possibilities here. Try to bring a couple of peers with you because this way you'll be able to talk through the test later and see if you all had the same impressions. It's also a good idea to assign one of them to take notes. So here's a tip Set the vibe with the tester, right? Guarantee that they know that you won't be upset if they're bluntly honest about what they think You can also ask the tester to narrate what they're doing out loud, much like pair programming, as this can help you understand their thought process And also remember that at the end of the day, you're trying to validate if the solution solves your users' problems or not. So tweak the solution after gathering insights. Alright, so you've gone through the value and usability tests, and it's now time to see if your team can actually build this.

This is where you usually come in as a tech person. And when understanding the technical visibility of something, we usually want to answer questions related to like how we're gonna do it, if it's gonna perform well, if we have the time and resources to go through it, uh, if we have the skills to do it, and so on. And I don't want to suggest a specific method to perform the sort of validation. I bet the tech leads and senior developers here know way more than I do. But the ones that I'm most accustomed to are RFC, so requests for comment, spikes, and also tech visibility meetings alongside the design team. And of course, right, giving time to engineers so they can ponder effectively on the solution. So the RFCs that I've taken part in usually have an owner who researches the feasibility of

a certain solution and or like proposal and then write about the context, risks, advantages, disadvantages, implementation suggestions, and so on. And they're really good for discussing async with the rest of the team and also serve as great documentation later on. Cards are usually a good way of assessing visibility too. I usually use them for smaller ventures that don't necessarily require an RFC. And they're tickets that have the unique goal of assessing the feasibility of a solution, which can be done through studying documentation, producing a proof of concept, and so on. As for tech visibility meetings with designers, uh, they're a good way of introducing ideas to an engineering team while they're still on the design stage. But they're not meant to be a silver bullet for capturing features that are not viable, only to generate initial discussion around the solution and also catch obvious errors.

So like the nitty-gritty would later on be tackled by a spike or an RFC So lastly, the you know business viability tests. Um I'm not very very experienced in this to be honest. I imagine that like PMs that are in single product companies directly get to do this more often. But testing the business viability of a feature or a product is a complex ordeal and involves a set of different stakeholders, like from the marketing team to sales, finance, board of directors, and so on. And I won't go into much detail here, apart from the fact that after validating all of the steps above, this is the final boss that will help you determine whether you have a profitable solution in your hands or a good but not very practical idea. Um let's now quickly get into the delivery.

And for time-saving purposes, I'll just mention that there are various agile and non-agile frameworks that can be used. And for what it's worth, I usually uh most mostly use Kanban as it emphasizes flexibility. Um, but there's no cookbook for doing good work and it's very possible that you have a different way of working in your company. Uh so the workflow is how we operationalize the execution of our objectives and returning to how everything fits It's during execution that we take our objectives, apply all of the concepts about product discovery, execute, and finally reach the result. Anyways, you probably know the drill about that, right? So we discussed a lot about the strategy. We validated that our ideas are good and we released our product.

Um now what, right? Some people could argue that we can call it a day, but how do we know if we actually impacted our users For smaller businesses with small user bases, this may just be a matter of asking around. But when you deal with a lot of data, you may want to look at the numbers first. So, product metrics show you how well your product is doing and how users are using it. And these will help you understand your product's performance and also make improvements where needed. There are a multitude of metrics that businesses can leverage. And if we analyze a subject, uh it branches out into frameworks for tracking these metrics. various types, techniques, etc. But the point here is that there's no formula and a business may use different tools to measure their results. Like the heart framework introduced by Google, for example, which measures happiness, engagement, adoption, retention, and task success

and breaks it down into goals, signals and metrics like the ones in the example shown, uh about like engagement and retention of users Or even like the R, so like pirate metrics for which there's a book out there which explains how to use them. Or the North Star framework, which is the one metric that is like of utmost importance to a business. Like there are several of them. But the important part of here the important part here and what I would like to leave as a takeaway is recognizing when it's time to become more metrics driven. And this shift typically happens when your product has grown to a point where qualitative assessments alone can't give you a full picture anymore So initially, when your product is smaller or just starting out, qualitative feedback like user interviews,

anecdotal uh evidence, and also observational insights uh can be extremely valuable and sufficient for guiding development of improvements. But as your product scales and you start reaching a larger audience The complexity and volume of data increase. And at this stage, relying on quantitative methods can lead to gaps in understanding your users' behaviors and also your products' performance. And this is when adding quantitative metrics becomes crucial because these can provide hard data and trends that qualitative feedback might miss , which will allow you to make more informed decisions backed by numbers. So uh our time here has come to an end. I wish we could discuss some of these subjects in more detail, but our time is short and the product world has a lot to cover.

So to wrap it up, I'd like to bring up the three main topics that I believe are fundamental to what we talked about today. So the first one is about the role of product-minded engineers in the team in the org. We saw how this integration between developers and product is an essential to the majority of teams. Affecting not only uh people's individual careers, but the ultimate success of the business. We also saw how the strategy goes uh from its most broad to its most specific, like a funnel Um, and how engineers can use the org strategy in their favor. And finally, uh, we also saw how we can better understand our users and save our resources through product discovery by validating ideas before they're even launched, as well as how engineers can contribute to this validation.

I bet you all are very tired by now. I tried to squeeze in as many product topics as I could into the starter pack But of course, no list will be comprehensive. So in case you're wondering where you can learn more about product matters, here are some blogs that I really enjoy. And I'll make the slides available later so you can all have access to this. I'll just wait for you guys to take a picture. All right. All right. And the main inspiration for this talk was No Pun intended, inspired by Marty Kagan And here's some other references which help me build this. I hope you enjoyed the talk. Here's my LinkedIn in case you want to get in touch. I'd be happy to connect with you all and answer any questions that come up.

So I'd just like to thank you all and I'll be taking questions in the hallway. Thank you.