Just Say No: Hard Decisions in Product Management "Product people - Product managers, product designers, UX designers, UX researchers, Business analysts, developers, makers & entrepreneurs February 02 2015 True Prioritisation, Mind the Product Mind the Product Ltd 588 Product Management 2.352

Just Say No: Hard Decisions in Product Management

BY ON

Warren Buffett, a slightly successful investor, once said, “The difference between successful people and very successful people is that very successful people say ‘no’ to almost everything.” Swap person for company and qualify company with technology startup, and not only is it an informed statement, it’s an absolute fact.

At the start of the year, product management organizations work with their colleagues across the business to determine the game plan for the coming annum, not only for the product roadmap, sales strategy and marketing calendar, but for the business as a whole. A common artifact of this activity is often an endless list of features and products, then immediately followed by a gasp of “How the hell are we going to do this?!?”

So, how are we going to do all that? Easy: We’re not going to do all of it.

Of course, that’s easier said than done. Features are on these lists, because someone has identified some value with each item. However, whether a company is Google-sized or is an early-stage startup, resources are always finite and tomorrow always comes quicker than expected, making proper prioritization imperative.

feature prioritisation

Prioritization within the world of product development is not a matter rank-ordering features by some single measurement and choosing the top X features that the team can bite off, but rather involves weighing many attributes of the feature (benefit to the business, cost to build, complexity, dependencies on other features, etc) against each other; this process of conjoint analysis allows all stakeholders to participate in the process to surface the products and features that are of highest value when compared against others under consideration.

Some questions to ask yourself when prioritizing include:

  • What do we want to do? Identify high-level business themes. Each major project should help achieve success against one or more of the themes for the year. A theme-based approach also helps to avoid a focus on potentially non-impactful projects.
  • How will this feature benefit the business? Of course, benefit may have different meanings, including objective, measurable impacts on the business, such as revenue, or something softer like generating buzz in the industry. But if the positive impact of having a feature as part of a product cannot be clearly identified, then ask yourself: is it worth the investment required to build?
  • What is the cost to build? Cost can be monetary, but generally with software development, cost is calculated by the man hours required to build. In addition to being a parameter for prioritization, the development cost will drive the relative prioritization and timing of other projects.

The output of a solid prioritization plan may surprise stakeholders when features that initially seemed to be must-haves end up on the cutting room floor. An effective plan for product development includes prioritization as its most important facet and creating that plan requires the discipline to use data and analysis to strategically say no and to say it often.

A “hell, no!” should be used on the seemingly must-have feature that might generate immediate but short lived value (whether that’s revenue, short-term industry buzz or the like). Effective product management requires looking beyond the horizon with a full 360-degree view. Figuring out what’s important and ask whether your limited resources are laser-focused on moving forward on the top themes.

Even with a flawless prioritization strategy, there is one item that any startup product guy would kill for. Engineering team please note: please build a day with 36 hours – all other feature requests will be no’d.