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

Just Say No: Hard Decisions in Product Management

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.

Comments 3

I would also like to see a larger version of that image, at least the criteria headings and legends.

The headings will be criteria like Revenue Generation, Gross Profit Generation, Appeal to Clients, Appeal to partners, Appeal to Investors and some variation of Cost to build, time to build and complexity which all go to “what is the cost and/or opportunity cost of building this instead of something else”. Also quite popular is “Company x core competency” as it is pretty common for a seemingly good idea to come up, but it is really far from what the company is good at already and needs to be evaluated through that lense in order to be properly evaluated. Finally, what you don’t see in this process is a bit of work before this project/criteria scoring where you brainstorm your criteria (what criteria should we use to evaluate our opportunities) and then do a binary analysis against all of them in order to get a ranking of criteria that can provide you with weighting. The idea being that a 5 in Revenue Generation may be much more important than a 5 in Appeal to Partners and that should be accounted for in your process. If you’d like more information on this process or some samples of the entire process, feel free to email me at steve.carter AT Gmail.

Join the community

Sign up for free to share your thoughts