Kent McDonald writes about and practices software product management. He has product development experience in a variety of industries including financial services, health insurance, nonprofit, and automotive.
Along the way he’s had the chance to see the world of product in a variety of different organizations. These organizations range from a small non profit - Agile Alliance - to large corporations such as Wellmark Blue Cross Blue Shield, Principal Financial Group, Corteva General Motors, and Wells Fargo.
All of those experiences inspired Kent to share advice with product people working on products used inside their organizations. He publishes this advice through his company KBPMedia and a variety of other outlets.
To keep his skills sharp, Kent practices his craft as a freelance product manager and participates in a variety of virtual and IRL product communities.
Kent is known primarily for content, curation, and community.
The foundation of Kent’s product career came as a business analyst, which inspired his three books. Kent is the co-author of Stand Back and Deliver: Accelerating Business Agility. Kent went on to write two additional books: Beyond Requirements: Analysis with an Agile Mindset and How To Be An Agile Business Analyst.
These days, Kent writes content for a variety of companies including airfocus.
Not sticking to the written word, Kent has a history of involvement in a variety of professional communities. After long stints actively participating in the business analysis and agile communities, Kent now hangs out with fellow product people. Currently he’s one of the organizers of ProductTank Des Moines/Ames.
If you work on a product that’s used primarily by people inside your organization, you may enjoy his weekly Inside Product newsletter.
And you can see all of his posts at his Authory page.
Use a filter, not a bucket, for prioritization.
Todd Little has established the metaphor that proper strategy is a filter, not a bucket. What he means by that is you should use your strategy to decide what you will and (more importantly) will not do. Your strategy should be a filter instead of using your strategy to categorize things into one of a series of buckets, without excluding anything.
If you prioritize using a bucket, it’s easy to fall into the trap of delivering everything in a given bucket because, well, it’s in that bucket. If you prioritize using a filter you’re very picky about what you actually do and throw everything else out.
Those outcomes that everyone shouts about focusing on are your filters. When you decide what outputs you’re going to deliver, pick the one that helps you make the most progress toward your desired outcome - ignore the rest unless you need more help getting to that outcome.
Prioritization grades (Value vs effort) can very easily turn into buckets where you’re inclined to believe you need to deliver everything in the high value low effort quadrant (ie bucket) even if they don’t drive progress to the outcome you’re focusing on right now.
Be clear who your customers and users are.
The customers of your organization are those whose needs you’re trying to satisfy through building or updating the product. They give your organization money in exchange for some product or service.
A user is anyone who uses your product. They may be inside or outside your organization.
You determine the right thing to build in a broad sense based on what will satisfy your customer’s needs. You then need to balance that with what’s best for your business as a whole (not select people within your business).
You consider users when you make design decisions. You want to build your product in such a way that people choose to use their product if they have a choice, and people look forward to using it if they don’t have a choice.
The key point: you should understand the relationship people have with your product and the perspective they hold, and then work with them accordingly.
Consider purpose when making a build versus buy decision.
When you’re working on a problem and your choice of solution is using an existing product or framework or building one, consider the nature of the activity you're working on before immediately deciding to build something.
The purpose based alignment model is a helpful tool to help you make this decision.
When you’re working on a solution that is essential for your organization to do and that adds market share (a differentiating activity) it makes sense to build that solution in house in order to maintain your competitive advantage.
If you are working on a parity activity (important for your organization to do, but does not drive additional market share), a wise course is to see if there is a product in the market that you can purchase and use with a minimal amount of customization.