Product feature validation and iteration – for product managers Today we are talking about tips for selecting, planning, and prototyping product features. To help us, our guest is Matt Genovese. He is the Founder and CEO at Planorama Design. He has in-depth experience marketing products, addressing product requirements, research, UX design, and management. He spent the first half of his 25-year engineering career in the semiconductor industry as a chip designer and the latter half in software product development. Summary of some concepts discussed for product managers [2:33] What issues have you seen in your career in both hardware and software when selecting product features? In hardware, features are normally planned out well ahead of time. You do not have the rapid iteration capability that you have with software. Hardware tends to use more of a waterfall process. You have to capture feature understanding from customers upwards of a year before you release the product. In software, projects can be never-ending, but we do have the ability to learn as we go along. We try to learn little bits about what the customer needs and turn that into value we can build into the application. It’s very useful to start small and mitigate risk. You may not even have to build an application to validate your features. Sometimes you can build a quick prototype to test if value is being delivered. [4:43] Do you have an example about starting small to do validation? A friend was working on using large AI language models to help analyze data and produce some metrics about the data. To test this, you might not need to build an application. You could produce a CSV and ask the customer if that is the output that solves their problem. Then, you can fine tune based on what they need and build a script that produces that output. [10:12] What do you do when the engineering team isn’t listening to the product managers? Engineers usually strive for perfection. Customers just want their problem to be solved. Those goals don’t always mix well because “perfect is the enemy of good enough.” There are different options to address this. The development team probably has technical debt they want to address. They want to make their application perfect because they know in the future they’re going to have to rewrite code or redo something. Allow time for that technical debt to be addressed. You can’t just keep pushing it out because it’s going to catch up with you at some point. Developers may design a product that’s easier for them to use so they can get it out sooner. Their motivations are good, but customers may not use the product if it’s not designed for them. Product managers have to be the advocate for the business and meeting the customer’s needs. [18:25] How do you select product features to implement? There are different ways to address it. One is to ascribe value to each feature. That value may be value to the customer or business value. You can use the ascribed value to select which features are most important. Also, think holistically about the features—not only their current impact but also their future impact. If you need to get a high-value feature done right now, you may need to do a bunch of redesign later. Consider if you’re going to paint yourself into a corner by building a feature now. One of the values of UX design is ensuring you’re giving yourself room to expand in the future. Think about how that feature is going to play into a larger set of features later on. Also think about the administration needs of a feature. For example, you may need to adjust pricing. When you’re building a feature, plan how you will manage it. Consider the entire scope of work so you’re not surprised later. In engineering, design is a necessary component. In software,