Product managers operate in the gap between product vision and reality. You’re asked to create a strategy and roadmap for your product, setting future expectations across a broad community including customers, sales, and engineering. Do your job correctly and everyone is energized with a bright product vision. But what about the inevitable inaccuracies in your forecast?

Product strategy involves forecasting where your market, customers, and products will be over time. The product roadmap is a forecast of how you will execute on the strategy, including assumptions of pricing, use cases, and development velocity. Get any of these substantially wrong and the strategy will fail.

Everyone recognizes that forecasts have inherent inaccuracies. The product manager is responsible for addressing subjective questions of acceptable risk and forecasting. And here’s the rub: who’s to say what is overly aggressive? We’ve all seen situations of overpromising and under delivering. Being too conservative creates grave disappointments as well.

You can do better than that

It’s too easy to allow wildly optimistic assumptions to guide strategy and roadmap by saying that all forecasts are inaccurate, so we’ll figure it out later. Early in my product management career, I experienced the personal discomfort of defending the indefensible and watching customers, sales, and engineering become disillusioned when the inevitable shortfalls became apparent. Those situations taught me to push back on glaring inconsistencies and force conversations on what is plausible versus fantasy. Though requiring more effort up-front, this approach builds trust with your community and allows your organization to focus its resources where they can truly succeed instead of being spread too thin.

Here are a couple of real situations which can be related to many IT products where I took my earlier learnings and influenced defensible product plans.

“We need to support three more storage arrays and two more versions of Linux in the next release.” Platform support is the gift that keeps on costing: more development, more QA, more equipment, more dependencies across third-party products and versions. With every new customer interaction, your organization will be tempted to support new platforms and interfaces. Unchecked, the situation will deteriorate into disappointing product quality, longer execution, and unfulfilled customer expectations.

The product manager needs to be brutally analytical in identifying what platforms will truly move the business and be prepared to decline some business opportunities to strengthen her core market. The specifics vary substantially by circumstance, so there’s no formula to follow. I’ve stood my ground with senior executives, account teams, and customers to ensure we supported platforms that are sustainable and that maximize revenue in our target markets. Doing this requires accurate data on adoption rates, use cases, and competitiveness in target markets.

In one particular case, a CTO lobbied aggressively to support a platform for a market we were poorly prepared to serve. I pushed back by showing the totality of what would be required to win such business at scale. We ended up serving that market, albeit later on, with an existing platform that played to more of our overall strengths.

“Let’s accelerate a release for our large customer in May, then do a summer release with the features we’re announcing at the tradeshow, and deliver the rest of the originally planned features in the fall.” Agile development processes may enable a faster release cadence versus waterfall. Your team may be faster than others. But light only travels so fast and you’ll eventually hit a wall trying to deliver too much too quickly. Quality and customer satisfaction will suffer.

Though it’s good to be aggressive, setting your business on a path you know can’t work is indefensible. The product manager has an obligation to speak up during release planning meetings and dig deeper on the assumptions and dependencies driving what appear to be overly optimistic plans. I’ve presented our agreed priorities to my business’ leaders and restarted conversations about what we’re willing to trade off to increase success in core business goals. It’s far better to have a frank conversation now than to run out the clock with unhappy customers and a wrecked roadmap later.

The last time this happened, we went back to the large customer, negotiated a phased delivery that aligned with our broader business goals, and consolidated into fewer releases we could execute on. We didn’t get everything that everyone wanted, but we kept the customer in the boat and met our announcement commitments. We managed the impact proactively.

A bigger payoff in the end

If you’re like me, you want to solve people’s meaningful IT problems and make them successful – “yes, we can do that!” Remember that success ultimately lies in delivering a solution versus the initial euphoria of delivering a roadmap promise. Ensure your team is defending only what is defensible. While the product manager needs to take risks involving imperfect forecasts, she’ll maximize her success by questioning glaring inconsistencies and unlikely dependencies to build and execute a defensible product plan.

Product managers are guardians of limited resources. Your business is on a budget and you’ve got to maximize value for the investment made. Let me start again: successful product managers are fierce guardians of limited resources.

You need a good answer when anyone asks why your engineering team built, or is building, a feature. Your organization agreed to spend its limited resources and the ‘why’ must reflect causal value. Random, inexplicable projects form an excellent hammer to shatter confidence in product strategy and product management leadership.

Far beyond producing a plausible answer on the spot, the product manager must ensure behaviors and actions that yield consistent, defensible product decisions over time. Three types of organizational situations shape your leadership approach.

Engineering does what it wants

“I’m not sure…ask engineering.” This is not a good place to be, as you’re a product manager in title only. Engineering has taken product management responsibility – justified or not, explicitly or otherwise. They may be doing a great job…or not.

Your choice is to find another gig, capture use cases and value justification after-the-fact, or influence a fundamental change in relationship. Only the latter will ensure consistent, defensible product decisions over time. (If engineering is truly doing a great job, either join them or refer to option one.)

A focus on product management basics – market opportunities, customer use cases, competitive position – goes a long way towards Influencing a healthy relationship with engineering. You are fully enabled to define a product vision grounded in differentiated value to customers. Articulate the gap between what is being built and what will maximize overall value. Your leadership can bring engineering, sales, and marketing together with objective data and common business goals.

Your predecessor screwed up

Take nothing for granted when you’re doing a turnaround. It’s important to quickly get your organization on a stable path and stop the bleeding of poor product plans still in progress. I’ve done several things in these situations.

Clarify product strategy. You need to know why your product exists and what value it can deliver over time. The organization around you needs to share that perspective to build and sell it effectively. Be your product’s worst critic and lead the definition of sustainable value and differentiation. Don’t assume the strategy you’ve inherited is correct.

Own the user experience. Knowing your product’s reason for being and who it’s meant for is the first step in identifying valuable use cases, which leads to articulating a compelling user experience. Soliciting feedback from existing users, listening to those in your organization who interact with your users, and assessing competitive products are ways to get started on user experience. You’ll need to perform primary research on new technologies and use cases when dealing with completely new products and markets.

Reboot product requirements. Documenting requirements becomes much easier once you are confident in exactly what your product should do. It can be tempting to edit requirements documents that you’ve inherited. Don’t! Force yourself to understand and think through every use case and requirement by rebuilding from a clean sheet of paper. Copying and pasting from questionable sources will subtly constrain your turnaround and allow inexplicable content back in.

You manage the product

If you’ve read this far, it’s clear that product managers should perform the responsibilities mentioned above on a continual basis to maintain consistent, defensible product decisions over time. Your dynamic world means that these processes are repetitive, not performed once. When sales or another stakeholder inevitably asks a question you’re not comfortable with or an important aspect of your business isn’t clear, consider it a turnaround situation – your predecessor is you.

An experienced product manager and I were chatting over drinks about our chosen career path. In response to my typically enthusiastic assessment that product management is the best job, he observed that product managers can get niched over time and excluded from new opportunities in adjacent markets.

“How quickly will this product manager add value to me?” is the question on every interviewer’s mind. The flip side is, “how much effort will I need to invest getting this product manager up to speed?”

Such personal concerns shape the product management recruiting process, creating subjective filters on skills and experience. Just as the recruiting process can niche senior product managers into narrow perceived swimlanes – she’s a storage person, he’s a Java guy – it can be brutal to those trying to get started without the “right” experience.

A product manager’s time to effectiveness is a function of her domain expertise in a target industry and functional expertise in product management. Interviewers assign varying importance to each variable based on their perceptions of organizational need and existing capabilities.

I’ve spoken with product managers across the seniority spectrum about ways they can make a successful career transition. Some are starting out, wondering how to demonstrate their potential. Others have years under their belts and want to work with new technologies. They’ve all faced the need to lower their perceived time to effectiveness during the interview process.

Smart interviewers will quickly identify a candidate’s lack of domain expertise or product management experience. Don’t try to bluff your way through experience by cramming the night before your interview. Bluffing, or making things up, kills credibility with a smart team. So what to do?

Threats and opportunities

By all means, demonstrate your domain and functional expertise. Showing that you can quickly learn a new technology or skill has great value. The conventional wisdom about coming prepared to an interview is absolutely correct. It’s disappointing when a candidate can’t muster a basic narrative about their aspirational employer or industry, thereby wasting an opportunity to demonstrate learning capacity.

Yet these basic learnings won’t mask a clear gap in expertise. Thinking back to the interviewer’s mindset, however, provides a great opportunity to show how you will add value as a product manager from day one.

Beyond daily product decisions lies your broader responsibility to guide product strategy based on market threats and opportunities. While both benefit from domain and functional expertise, threats and opportunities require a wider lens to detect inflections and adjacencies. Myopia induced by being too close to a product or technology can be as deadly as the reverse. Your fresh perspective can be tremendously valuable – if you demonstrate capability and vision during the interview.

I’m impressed when a product manager candidate pushes back on our strategy and points out inconvenient weaknesses in our narrative – and we all have our inconveniences. Or when she recognizes an adjacent, emerging use case we have not publicly disclosed. Such observations become far more powerful when followed with strategy proposals to minimize risk and capture new opportunity.

Product managers are recruited to be leaders, making these interview experiences tangible examples of how the candidate will immediately add value. Though acknowledging the candidate lacks the “right” experience, the interviewer can internalize a vision of strong leadership and strategic reasoning. The candidate’s time to effectiveness is reduced.

Worth the effort?

Sufficiently researching your prospective employer and industry to develop a defensible thesis of their threats and opportunities takes time. You may wonder if doing this for every interview is worth the effort. Not doing so is a huge disservice to you. Committing yourself to a business with unknown risks is gambling with your career. First, know the risks you’re signing up for. Then, develop a strategy to reduce those risks when placed at the helm as product manager. You’ll go into the interview being able to tell a relevant narrative.

A day in the life of a product manager brings many diverse responsibilities and tasks, which is one of the reasons it’s such an interesting career. This diversity, however, can lead you down unintended paths that divert you from being successful. Actively managing your daily tasks and longer-term goals is not your manager’s responsibility, but your own.

There are many good descriptions of a product manager’s job – I won’t reinvent the wheel here. A product manager’s core responsibility is ensuring a viable overall business, requiring continual engagement with many peer groups, each of whom seeks her guidance and assistance on a daily basis. There’s a blurry boundary between active engagement and doing someone else’s job that changes according to market, product, and organizational maturity.

The product manager must ensure that engineering has a clear vision and plan to build necessary capabilities at the right time. Whether due to market disruption or building a new product, the product manager may become more deeply involved in product design than with a more mature product. She may be called upon to verify that engineering prototypes actually deliver necessary use cases. She may need to specify detailed user experience elements. She may be asked to help make architectural trade-offs with ramifications on delivery timelines, product scalability, and usability.

Purists could argue that the product manager should draw a line at defining use cases and let engineers, user experience designers, and functional architects work it out. Such neat circumstances don’t exist at startups or new product groups. Letting her business fail on job definition grounds would be the height of negligence. The product manager jumps into the void and does what’s needed.

Similar situations arise on the outbound, or customer-facing, sides of a product business. Sales won’t be able to engage customers on their own in the early days of a new or disrupted market. The lack of reference customers, established buying patterns, and stable product means that a sales rhythm is not yet established. The product manager will be called on to evangelize her product’s value, defend competitive attacks, and deliver a product vision and roadmap directly to prospective customers. Rather than say it’s the account manager’s job or a pre-sales engineer should give the demo, the product manager will be out selling.

Fallacy of extremes

I’ve seen product managers get trapped in the fallacy of extremes where they allow one important aspect of their role to overshadow other core responsibilities. Because so many peers ask for product management’s active engagement, plentiful demand and positive feedback reinforce the imbalance. The unfortunate result over time is letting these same people down when product strategy becomes obsolete or is dead on arrival.

Only in retrospect, having moved on to a new role, did I realize that I crossed the line and allowed myself to become too involved in functional architecture. I succumbed to the fallacy that I needed to be involved in all the engineering decisions and conversations that I was asked to participate in. For an engineer-turned-product-manager like myself, it’s easy to slide back into architecture as white-board conversations with developers descend into the critical detail of how features will work. I love designing and building products. Yet, by allowing myself to be drawn into core engineering responsibilities, I unwittingly spent less time on product strategy and it showed. Following the realization of my error, I resolved to be conscious of my broader responsibilities, continually triage my tasks, and avoid extremes over time.

A product manager can’t operate by rigid definitions. There are times when she must step over the line to bridge gaps. It requires awareness that she is temporarily wearing another person’s hat, that she will return the hat as soon as possible, and that she must absolutely find a way to wear the product manager’s hat on a daily basis.

Focus on balance

I’ve advised many product managers to be cognizant of their core responsibilities and avoid my mistake so they can maximize the value they bring to the business and, in doing so, strengthen their career trajectory. While we may enjoy in-the-moment satisfaction wearing another hat, product managers are ultimately rewarded based on their strategic contributions and not for doing someone else’s job.

The irony in this reality is that a product manager benefits from experiencing the successes and challenges of her peers. Spending time with each group yields a valuable 360-degree understanding of her business’ performance, opportunities, and threats. Being in a sales situation quickly clarifies competitive weaknesses and messaging deficiencies. Customer support experiences highlight product gaps that risk customer satisfaction. As with many aspects of life, focus on balance and avoid extremes that make you too busy to do your job.

In part 2 of this post, I wrote about two key factors that influence aspirational builders – talent retention and personal achievement. Accounting for ongoing maintenance and updating of custom systems can be a challenge not only for aspirational builders, but for vendors as well.

Product lifecycle

Vendor engineering organizations succeed by building products for many customers.  This leads them to design products for multiple use cases and degrees of scale. The product lifecycle accounts for deployment, support, patches/repairs, and upgrades in varying environments. These responsibilities contribute to customer perceptions that some vendors take too long to deliver on their requests. Product managers can make the mistake of building too many features and unwittingly fail to satisfy any customers due to a lack of focus.

IT operators succeed by deploying new services quickly to their business’ specific requirements. This leads them to evaluate the task at hand and implement exactly what is needed. Though they will sometimes be given latitude to think further ahead or to build for multiple services, urgent timelines and thin budgets often make these unaffordable luxuries. While this behavior can yield rapid prototypes or production systems that fulfill the need of the day, long term flexibility can be overlooked. IT operators may find themselves rebuilding from scratch rather than leveraging past efforts as the cycle repeats.

When IT operators do approach building a longer-term solution, lifecycle considerations and multiple use cases require time to incorporate into the design process. It took me longer to build my custom cabinets than a professional cabinetmaker would have required. The cabinetmaker has all the right tools and builds cabinets every day. I have some of the right tools and build a cabinet every few years. I’m simply not going to be as timely in replicating the cabinetmaker’s work. IT operators face the same relationship with vendor engineering organizations. The business imperative to quickly deploy a service to specific requirements takes priority and results in inevitable trade-offs.

Product managers regularly encounter situations where the product nearly matches the aspirational builder’s requirements, but somehow falls short. This forces the aspirational builder into a choice of employing workarounds until a new version is ready or building some portion themself. Rather than trust that a future version will address their needs, the aspirational builder may instead say:

“All I need is this one thing. I’m sure we can do this faster than the vendor.”

The aspirational builder may be correct. Yet, I’ve watched such customers underestimate the scope of work on multiple occasions. (To be fair, we all make mistakes sooner or later.) As the cabinetmaker observes daily variations on customer orders, raw materials, and tools and continually adjusts the manufacturing process, vendor engineering organizations do similarly.

While the product manager needs to respect the aspirational builder’s timeline and requirements, there is an opportunity to better understand their business requirements and use cases to identify alternative implementations that are cost-effective, timely, and that will make the customer successful. Often, it is not what is scoped to build, but what is missing from that scope that results in difficulty.

This is a great product management opportunity to build trusted customer relationships by getting out of sales mode and letting the conversation go wherever the customer’s success criteria take it. Each side has access to information the other may not possess. Customers have the benefit of speaking to multiple competing vendors, each helpfully pointing out flaws in others’ strategies. The product manager has the benefit of speaking to many customers and engineers, learning about how others are approaching the same use cases and where subtle pitfalls lie.

The buy argument

Making a case to buy requires the product manager to walk in the aspirational builder’s shoes and recognize legitimate reasons why the customer should not buy the product. This is a time for less marketing spin and more accurate analysis of the benefits and downsides of building what can, at least in part, be bought. If the customer is already biased towards building, marketing spin will be detected quickly and used as proof that buying is not in their interest.

Increasing the aspirational builder’s awareness of the long-term lifecycle dependencies in building and identifying which portions of the product are not required increase buy argument credibility – rather than trying to sell everything. The product manager has to be willing to cede some territory to build trusted customer relationships. When working through salespeople via collateral and sales tools, the product manager has to enable the same type of relationship by training the sales team on how to identify scenarios that favor buying or building and engaging the customer as appropriate.

Regardless of how individual customer engagements turn out, product managers have valuable opportunities to improve their products by adapting to new use cases for all types of customers, including aspirational builders.

In part 1 of this post, I defined the aspirational builder – a type of customer who wants to build something that is wholly or largely available from an IT vendor.  While there are famous examples of world-class IT shops that succeed in building their own infrastructure, it requires an organization and culture aligned to the goal.  This post will look at two key risk factors that aspirational builders face.

Talent retention

Everyone struggles to retain key talent in an economy where your competitor wants to hire your best people.  Beyond natural employee turnover, vendor engineering organizations can fail when they allow too much key talent to leave without hiring and training replacements in a timely manner.  Successful engineering organizations have critical mass to withstand a reasonable key talent departure rate.  They have staff development and recruiting to ensure continuity in product design and development.

Aspirational builders often lack critical mass in their engineering organizations due to overall business size or other business priorities.  Managers who decide to build a new capability instead of purchasing it implicitly create dependencies on talent retention.  Choosing to build means custom implementation and maintaining in-house experts who know intimately how the system works, how to build it, how to fix it, and how to operate it.

I’ve met aspirational builders as they are setting course for custom development who have introduced me to their team who will get it done – typically one or two experts whose stated goal is to reproduce a service similar to what one of their peers atop the built-it pyramid has done with tens or hundreds of engineers.  I’ve wondered if the executives sitting next to them are fully aware of the talent retention dependency being created at that moment, not to mention the business and technical risks being undertaken.

Not infrequently, the same executives reappeared a year later in our briefing center with a new plan, sometimes with a new technical team.  Employee turnover is natural for organizations of all sizes.  Depending on the state of development and organizational structure, such departures can cause serious disruption or outright failure.  Vendors are not immune, but it’s a question of degree.

As a do-it-yourselfer, I respect the aspirational builder’s desire to innovate, be free from the vendor’s limitations, and take matters into their own hands.  As a product manager, I take the opportunity to ensure the customer understands the magnitude of their undertaking.  In doing so, I can better understand my product’s limitations and the industry forces driving the customer’s decision.  This exploration may – not always – result in that customer rethinking some their scope and choosing to use my product to reduce risk or accelerate delivery.

Personal achievement

Building custom cabinets for my home is something I do not because it is the most practical way to acquire furniture, but because I enjoy it and derive satisfaction from the personal  achievement.  Aspirational builders share this mindset whether explicitly stating it or not, creating the challenge of influencing a decision with a personal underlying motivation.

Anyone who actively manages their career thinks about how their current job, responsibilities, and accomplishments will look to a future prospective employer.  Recognizing that those atop the build-it pyramid frequently publish papers and speak at industry events, aspirational builders wish to do the same.  The desire to work in a new area or employ a new technology to solve an existing problem can greatly influence build versus buy decisions.

Aspirational builders will ultimately be judged on their delivery effectiveness; how an IT project is implemented is secondary to delivering on-time and on-budget.  A project is composed of many individual pieces, each of which has more or less achievement value.  The aspirational builder may ideally wish to build everything, but instead recognize an easier path to success by including off-the-shelf products, while preserving the key personal achievements being sought.

The product manager has an opportunity to build a trusted customer relationship by understanding the aspirational builder’s overall success criteria and respecting their desire to build key portions.  More broadly, these learnings can be applied to the broader market segment by describing a class of use cases and associating product elements with each.  The product manager may uncover product gaps – usability, functional, licensing – that, once resolved, make the case more appealing to aspirational builders.  It takes a willingness to look at the product from the customer’s perspective and critically ask what the decision would be if the tables were turned.

It works, we’re done!

Building what amounts to an in-house IT infrastructure product merely represents the early steps in a longer product lifecycle.  Day two and beyond becomes the real test, which I’ll cover in part 3.  Send me your views on working with customers’ navigate build versus buy decisions.

Soon after seeing a product I would like to have at home, my thoughts rapidly turn to evaluating if I can build it faster, better, or cheaper. The thought of building it myself, to my specifications is a temptation I have given into on many occasions. The DIY Network was made for me!

Are my decisions “correct?” To be honest, it depends on my success criteria. The enjoyment/hobby factor weighs strongly to the positive. Home-built projects usually (not always) cost me less than buying off-the-shelf. Quality varies according to the importance I place on the finished product, how frequently it will be used, and whether it will be on display. Custom cabinets are used everyday and are readily visible. My home-built vacuum forming machine is used rarely and stored in the garage. Time, however, is not even close. The cabinets took me weeks to build and the vacuum forming machine more than six hours. Taken alone, converting time to money using reasonable hourly rates makes my endeavors look dubious. Of course, I build because I enjoy building.

Throughout my product management career I’ve seen IT professionals make their own build versus buy assessments. Many are definitively in the buy camp. Whether for lack of interest, time, expertise, or something else they make no pretenses about building custom IT systems. These customers want to focus on their day job and not divert attention and resources to building what can be reasonably bought.

A few IT shops have world-class IT engineering organizations and the conviction that they can reliably and repeatedly build systems to their own specifications with better overall outcomes than buying off-the-shelf. Those success criteria may be overall cost, but more often it is something more. These organizations view IT as a business advantage more than a cost center, believing they can deliver new services faster and better by building their own systems. Their engineering teams rival or exceed the capacity of many IT vendors. They have a critical mass of talent sufficient to attract, hire, and train new talent. Their scope allows for career development and advancement on par with vendor engineering departments. They routinely publish research papers, file patents, and share their progress as guest lecturers, in blogs, or at meet-ups.

The aspirational builder

That leaves a set of IT organizations in the middle who appear to want to build much of their IT landscape, but struggle to reliably and repeatedly generate business value from their efforts. I’ll refer to this type of customer as the “aspirational builder” who often has most of these characteristics:

• Fortune 1000 organization with strong buying power
• Capable engineers and managers on staff who keep up with industry trends
• Share their accomplishments with others
• Vision to offer new services where IT differentiates the business

I see familiar aspirational builders at industry conferences and sit in the same sessions listening to their world-class peers discuss their latest project. Seeking to emulate their peers, aspirational builders set out to create systems of their own while avoiding the marketing efforts of IT vendors, who intensely compete for their high-volume business.

Surely, IT vendor products are imperfect and vendors have been known to oversell a product’s capabilities and benefits. Given such risks, why shouldn’t the aspirational builder create their own system? When something goes wrong, engineers are already on-site, rather than having to wait for the vendor to respond. IT problems often reach across vendors who point fingers at each other to deflect responsibility. Furthermore, in-house development may allow the aspirational builder to purchase commodity products at lower capital cost, helping to defray development costs. Slam dunk!

Product managers should understand and respect three key factors I have observed that influence aspirational builders, the goal being to develop relevant products and meaningfully engage these customers:

• Talent retention
• Personal achievement
• Product lifecycle

Part 2 of this post will begin to explore these factors that heavily influence the success of any organization choosing to build core capabilities. Any type of organization can theoretically manage these things, but lack of awareness can be a critical stumbling block. Send me your views on when IT shops should build or buy.

Well-intentioned prioritization exercises can quickly go from pointless to delusional and actually harm the business your team is trying to nurture. It can happen early in budget or release planning or it can happen late in the development cycle when overly optimistic product plans meet the reality of what engineering can actually deliver.

“Product managers: we need to review your prioritized feature list. Let’s get one list from 1 to N and we’ll draw the cutline based on our budget.”

Clearly this is a call for help, but the answer isn’t to comply literally. Prioritized lists set false expectations that an arbitrary cutline will preserve meaningful business outcomes amidst the items remaining above that line. This holds true across the hierarchy of portfolio, products, goals, use cases, and features.

A single use case may be realized via several features in a product release. Arbitrarily removing one of those features that falls below the cutline breaks that use case. Other use cases may be preserved, but we won’t know simply by looking at individual features in a prioritized list. Each use case is an atomic entity that either works or doesn’t.

Similarly, I may have a business goal for my product such as increasing sales by supporting a new end-user process. Meeting that goal requires a set of use cases. Once we agree on the set of minimum viable use cases to fulfill the goal, they become an atomic entity. Breaking one of these use cases via a cutline will substantially degrade or outright deny our ability to meet the goal.

I’ve seen cutline prioritization and budgeting exercises occupy teams with busywork that fails to generate useful outcomes and merely consumes time generating 1-to-N lists that everyone knows are useless. Stack ranking products at the portfolio level is a great way to divert productive teams into manufacturing prioritization logic merely for its own sake and encourages political posturing versus substantive portfolio analysis.

Meaningful prioritization

Of course, prioritization is critical to the product management role. Beyond the reality that we can’t fund every ask, product managers have a fundamental responsibility to prune activities that are adding insufficient value so those resources may yield greater outcomes. Be clear on the minimum viable outcome (MVO) for your portfolio or product, rather than creating a simplistic stack ranking.

Apart from my MVO, of course, I may develop lower priority desired outcomes where a budgetary analysis can be used to establish a cutline. This prioritization must operate on atomic entities, preserving whole outcomes and enabling conversations about what varying funding levels can achieve for the business.

My CEO once tasked me with the goal of delivering a wholly new patch management capability that would allow my product to double its penetration within our largest customer and simultaneously address a resurgent competitive threat in our market. The goal was part of my company’s MVO and received substantial funding. However, we couldn’t satisfy every use case in the first release given time-to-market requirements and finite resources – nothing unique about that.

While identifying the minimum viable use cases required to meet the goal, we documented opportunities to deliver more value that would go beyond parity with other products and give our product a clear competitive advantage. Many of those use cases had to be deferred to subsequent releases. Yet, we succeeded in building use cases beyond the MVO that tied the new patching capability into existing product capabilities including compliance auditing, creating more compelling user experience and competitive differentiation than a standalone patch manager.

Though our prioritization analysis occurred at the atomic MVO and use case levels, we inevitably came across difficult trade-offs upon learning that certain features would take longer to build than expected. In one situation, we made the hard choice to delay the release rather than ship a compromised product with partial use cases that failed to meet our MVO. In another situation, we introduced a second release to phase in highly desirable use cases that were beyond the MVO, but which we knew would improve customer satisfaction and competitiveness.

Making the cut

There’s no way to avoid making tough priority calls, but the product manager must prioritize in a way that recognizes minimum viable outcomes rather than inadvertently undermining them with arbitrary cutlines. Don’t let an impromptu request for a prioritized list create a delusion at odds with your responsibility in guiding the organization towards viable business outcomes.

“Mark, the customer needs to see our five-year roadmap.  When can you do the briefing?”

Whether I’m managing a multi-billion-dollar product line, a pre-revenue startup product, or something in-between, customers expect me to have a vision for our intertwined future.  Customers evaluate vendors on their innovation and technical leadership.  Engineering and others within my company also expect and deserve a clear view of where we are going.

It’s easy for the product manager to remain fixated on the next year.  What product releases are planned?  What use cases will drive sales this year?  Five-year visions are great, but we need to pay the bills now.

Poor excuses.  A product without vision fails to energize.  Engineers want to innovate.  Customers want their product investment leading toward a better IT future.  Press and analysts become indifferent to mature technology.  A “meh” product attitude makes everyone nervous by risking competitive disruption, employee turnover, and tepid growth.

Defining product vision is a core product management responsibility, though not done in isolation.  I work with my CTO and other constituents including customers, engineering, and sales.  The CTO, in particular, checks my blind spots through awareness of emerging technologies that may disrupt my market or expand my product into new adjacencies.

Product manager vision

I start by asking myself what story I want to tell to in five years – the impact I want to look back and say we delivered to a specific group of people.  I don’t want to talk about saving 10% on operating costs.  Or making my product more scalable.  Sure, these are reasonable product release goals, but they don’t speak to a basic meaning of why we’re building products.

Instead, I want to achieve fundamental change in how individuals succeed in their professional lives.  For example: before, Sarah was stuck in a tedious job trying to keep up with an ever increasing load of IT problems.  Now, she is the architect for IT systems that proactively dispense tailored services for her user community.

Simon Sinek does a great job articulating what energizes us: “People don’t buy what you do, people buy why you do it.”  I remember Simon’s thesis when setting the five-year roadmap: my product needs a why.  More specifically, I want to offer a fundamental personal benefit that was previously unattainable or impractical.

A skeptic may say that my goal is ridiculous – my chosen industry is information technology, not improving medical care or education around the world.  IT professionals typically work in clean, air-conditioned offices and go home (most) nights to a comfortable home. Yet they have aspirations and burdens like everyone else.  Try to schedule lunch with a friend who works in IT.  There’s an even chance he’ll reschedule at the last minute because an emergency came up.  Or your other friend won’t be able to take a long vacation because that’s when a critical change window is scheduled and no one is sure how long the system upgrade will take.

Product managers for IT products can benefit users when we make their jobs easier and more rewarding by helping meet their professional goals.  Software Defined Networking came about, in part, to address the insane complexity of deploying and managing data center networks.  Hypervisors made deploying new services far easier by converting physical boxes to virtualized software servers.  Linux containers now promise to simplify software packaging and deployment for developers who want to finish their projects.

Guide users to their success

Every IT product faces disruption by those seeking to improve its users’ experience, often in the context of new operating models.  The five-year roadmap is a means to show my users how to navigate the changing IT landscape around them.  A few quick scenarios:

Changing consumption models

IT is moving to a self-service consumption model, with huge impact for IT professionals and products alike.  If you believe the future success of IT professionals is as facilitators rather than gatekeepers, consider how your product will enable users to successfully manage that transition.

Greater operational scale

Virtual machines increased application density by an order of magnitude.  IT products built for the pre-hypervisor world were largely replaced by virtualization-optimized successors.  The industry is now on the cusp of another dramatic density increase courtesy of Linux containers.  How will your users be affected by these changes?  Surely there are opportunities to make IT professionals successful in the long-term adoption of containers.

New technologies bring organizational change

The revolution in large-scale data analysis not only improves business decisions; it alters relationships and roles within IT.  Data is democratized and the insights they bring are accessible to a broader community than ever before.  Users and products organized around limited access to information are destined to change.  Better to lead that change along with your users.

The five-year roadmap doesn’t require you to invent a whole new industry. These examples illustrate the opportunity to address foreseeable changes from the user’s perspective.  Channeling Simon Sinek – ask yourself why you come to work every day.  That reason should be inextricably linked to your five-year roadmap.  Knowing how I’m making a positive difference in people’s professional lives forms my answer.

This post continues from part 1 where I observed that our macro obsession with efficiency does not automatically translate into the purchase of efficiency-boosting IT products.  Product managers may have good intentions, but there’s more to delivering overall efficiency than optimizing a singular IT process or function.  This concluding post will look at the costs our customers must balance against the benefits we claim.

How much does it cost?

“How much does it cost?” is largely under the product manager’s control.  Many vendors have historically tried to nickel-and-dime customers with excessive options and licenses.  My experience has been to simplify pricing with three or fewer options for a broad portfolio and just one or two options for a new product to remove licensing as a barrier to adoption.  The pricing decision gets easier when you’re not fixated on collecting every possible dollar from every customer.  When I introduced a new software product a few years ago, we optimized for sales velocity and priced one license for all product capabilities.  We subsequently added a lower cost option, but resisted the temptation to offer a la carte options.

Even when the product manager believes that cost transparency has been achieved, indirect acquisition costs come into play.  Other purchases may be required to deliver all of the required capability – rust-proofing anyone?  Some of these may be asset acquisition and some may be professional services or consulting.  The IT industry is littered with products requiring extensive consulting and customization to make them operational and deliver on the vendor’s promises.  I constantly hear customer feedback to make a product work properly out of the box.  Not long ago I called engineering and product managers together to set our priority around ease of deployment and overall usability rather than adding more features.  Product managers can drive their team’s thinking around the out-of-box experience (or, “I signed up for the service, now what?”) before assuming product usage begins once the product is fully configured.

How easily can I implement it?

This brings us to the third factor: ease of implementation.  It’s clear that consulting and customization services will add to implementation cost.  Are these one-time or ongoing costs?  Does the customer need to re-engage services whenever the vendor releases an update?  Customers may find it difficult to fully assess implementation complexity depending on the type of product in question.  Standard interfaces, wizards that step users through multi-step configurations, and sensible defaults are just a few ways to make easy things easy.  One of my product teams created a priority for automation software to include out-of-box wizards and workflows, enabling customers to be self-sufficient in product deployment.

Ease of Implementation goes beyond money.  The time required to deploy the product and get promised value can have a large impact on whether the product is viable.  IT organizations have busy times of the year and narrow change windows during which they deploy new products.  Subject matter experts are typically busy without slack time to indulge in extra projects.  The product is competing with other projects for each change window.  Higher priority projects to fix problems (aspirin anyone?) or roll out new business offerings can easily wear down motivation to “do the right thing” by increasing efficiency.

It’s no surprise that customers don’t immediately deploy new products that promise greater efficiencies.  Asking people to step through a detailed evaluation and navigate their myriad dependencies inevitably takes the shine off the desire to be more efficient.  I’ve watched customers in briefings get excited about a new way to improve data center efficiency, followed by the more sober assessment of the time and effort to follow through on the vision.

So who cares about efficiency?  Most IT professionals.

Should we continue building efficient products?  Yes!

There is a difference between caring about something and channeling that caring into action. If product managers believe that efficiency is important, we can build products that minimize barriers to adoption and effectively lead users through clear steps to be successful…and efficient.