As part of a recent job application, they asked for my responses to a number of interesting questions regarding my approach to Product Management. In the spirit of Scott Hanselman’s “don’t waste your keystrokes“, I’m sharing my thoughts to give more folks the benefit of my perspective.
As a “Product Manager”, what are the product management challenges in a Start-Up (Private) company environment?
Key is determining which of the possible ideas and market gaps you’ve identified are real winners with significant and long-term revenue opportunity, without the benefit larger, older companies have of market/revenue history to guide your guesses.
Choosing among an infinite range of new product ideas is much harder and feels more arbitrary than choosing among the more focused features and enhancements that an established customer base can provide you.
How do the product management challenges of a Start-Up (Private) company differ/compare to an established Fortune 500 environment?
In the established Fortune 500 companies I worked for, the challenges included weighing the benefits/risks of cannibalizing existing products, making incremental market share improvements in mature/low-growth markets, and how to encourage existing customers to buy more of the products you’re offering when you’ve maxed out their capacity to buy the ones they already have.
Start-up companies have the opposite challenges: establishing *any* market share in pre-existing markets (trying to gain visibility and credibility with target customers), making the “first sale” and determining what are the actionable and actual barriers-to-purchase in the market when you have few customers to quiz for any leading/lagging indicators.
Please describe (2-3 sentences) your experience developing a software product or service in a product manager role.
I’ve managed a range of software opportunities, from those I’ve birthed from scratch myself (and managed through many major releases and business needs changes over the years), to managing a pair of employee-focused productivity solutions, to juggling a wide range of developer-focused software solutions that had competing and sometimes conflicting customer requirements.
I’ve always managed teams “too small for the job”, and always focused on making sure they are more confident and prepared to deliver the software their customers actually need (no matter how unclear the initial requirements may have been).
My “business value” focus is weighted towards ensuring that the primary use case is never difficult to follow, that we design for the user with the least experience with/attention to the system, and that we’re always focused on making incremental improvements based on actual customer feedback rather than infinite analysis paralysis that halts good experiment-driven development.
Please describe your product management experience where “need” has been identified, but not “demand”.
The product I managed the longest was a set of business applications that I led because I was tired of seeing my colleagues sending around spreadsheets, and knew that they would be much better prepared and more effective with a centralized, real-time solution. I further determined that the engineers who were the day-to-day users of the system needed not only to know what they were expected to do, but how they were expected to know when they had successfully completed the required tasks proscribed by my solution.
Neither of these focuses were requested by my stakeholders and customers – in fact the former was something I was actively encouraged *not* to pursue by my management, and the latter was something that my management believed was irrelevant to the purpose.
In the end, this solution went from a system no one asked for or cared about to the most critical piece of infrastructure that measured and enabled the Security Development Lifecycle across Intel.
How do you deal with frequent product goal changes?
I have two main strategies I pursue:
I reduce the amount of time I invest into “gold-plating” (grooming, refining, updating) the roadmap or the product Backlog artifacts – up front I’ll define their “why” and primary goals, but I spend as little time as possible (sometimes just a few minutes based on my intuition and initial impressions) to refine these artifacts from e.g. “could be 10-40 points of work” to “I’m pretty confident this is 10-15 points of work”. I take this approach with the knowledge that (a) as the timetable approaches when we’ll actually deliver the items, (a) many of them will have been discarded [for which any refining effort would have been entirely wasted], (b) we’ll usually have to significantly revise what we were initially focused on as new market demands and insights become available, and (c) we’ll spend the least amount of wasted engineering cycles doing the final evaluation & estimation of the effort to deliver that work, by delaying the detailed investigation to just before they need to be delivered.
I stay tuned into all market/customer feedback channels – listening closely to Sales, Support and my direct customer interactions, effectively “leaning in” to the market/customer volatility to get a clear idea what how the fluctuations at our customers are turning into fluctuations in their requirements of us. For example, when a customer’s business is radically changing, or they’re subject to significant changes in what they’re expected to deliver (e.g. new business, losing their old business, changes in management or *their* customer base), that has significant downstream impact – they’ll frequently change their mind, or forget the last thing they requested. In cases where we have that kind of apparent chaos in the signals we’re getting from significant customers, I’ve made the effort to get directly in touch with the customer and have a longer conversation to help us understand what’s going on behind the scenes – and to help them prioritize among the stream of conflicting requests. This effort to “lean in” and engage the customer directly also has the beneficial effect of helping me determine which channels and individuals (e.g. sales, support) are reliable sources of information, and which ones warrant fewer immediate “drop everything” reactions from us.
Product Management when the customer’s problem/pain is identified is easy. How do you manage a product when the customer has not identified the problem/pain?
The classic answer is “ask them ‘Why’ five times until you get to the root of their problem”. However it’s rarely that simple – some customers aren’t able to articulate, some get defensive, and sometimes it takes a few rounds of conversation (with thinking in between) for them to articulate/admit what’s really going on. Some customers can own up immediately if only you ask directly.
In my experience, I have learned to ask the following question, when they demand a specific change or enhancement to the software I’ve helped deliver: “What decisions will you be able to make with this new information, or actions will you be able to take with this change in the system, that you aren’t currently able to make without it?” That, or variations on this question, usually helps me and the customer sort between “ideas that sound good or that make me feel better” and “those that will have a material impact on our business”.
The former are worth considering too – sometimes the usability, the pleasure evoked in a smoother experience, makes for a much more ‘sticky’ product (i.e. one which the customer is more likely to renew/purchase again). However, in my experience if you can’t identity or you ignore the latter in favor of the former, you risk allowing frustration and dissatisfaction to fester and ultimately doom your relationship with the customer.