Macadamian Blog

Prioritizing Features in Your Product Releases

Brian Lawley is the CEO and Founder of 280 Group.

When working as a Product Manager with an engineering team one of the biggest challenges you face is prioritizing what features are critical to include in your next product release. One of the most popular techniques for prioritizing features in an MRD (Market Requirements Document) or functional specification is to use the HML (High, Medium, Low) method.

Here are what the HML criteria represent:

High = Must have.
This is a critical feature that the market demands, and you would not ship the product without it. Reasons to rank a feature high might include revenue implications (will lose a big customer deal if it isn't in), competitive requirement to match or beat other products, strategic importance or even as a REF (Required Executive Feature - when the CEO/VP insists that a feature be included).

Medium = Nice to have.
This is an important feature that will help the product to succeed and be accepted by customers. Though you would ship the product without it, the product offering will not be as compelling if it is not included.

Low = Can wait if necessary.
This is a feature that could be dropped off the list without affecting the product's success. If it is extremely easy to develop and test it should be included in the product release. Otherwise it can be deferred if necessary.

To apply this technique assign an H, M or L to each of the features in your MRD. If you rank a feature as an H or M include one or two sentences explaining why it is important. Then have your team read through it (or present it to them in person to talk through all of the required features) before they sign off on the MRD so that you are all on the same page about what is critical for a successful release.

By the way, an excellent way to provide some context for which features are important is to use the concept of Themes for your releases. Combining HML and Themes can produce excellent results, and an MRD that is much more effective and credible for your team to work with. We'll be including an article on themes in the next edition of our newsletter, the 280 Insider. If you'd like a copy beforehand simply contact us by email and we'll be happy to send it to you.

Connected Consumers

Recently I attended Mobile World Congress in Barcelona. I know, tough life! One of the sessions I attended was on the connected consumer with panelists:

• Brian Dunn, CEO of Best Buy
• John Donahoe, CEO of eBay
• Michael Roth, CEO of IPG

There’s more to quality than quality

At Macadamian, we have a culture of constant improvement. The downside -we can be hard on ourselves, the upside - we are highly introspective about what worked and what didn't, when it comes to our projects. On every project, we find opportunities to improve for the next one.

After every project, we do a phoenix session, and the lessons learned are posted to our wiki. We release 40 - 50 projects a year, and about a year ago, we started to see some common threads. Although the details of the lessons were different on a process or technical level, we noticed that almost all of the issues we encountered on projects had to do with the connection points and hand-offs between teams and people.

This realization led to one of the most important improvements we made over the last year - the formation of a new working group called the Quality Triad, a group that consists of representatives from development, project management, quality assurance, and UX design. Their mission is to periodically look at our phoenix session data, and identify issues involving team dynamics and collaboration.

The result?

A whole host of improvements that include breaking down the silos between functions, requirements tracking, deliverable hand-offs, and overall quality. For example, there is now a lot more overlap between design and development, with designers being more involved throughout development to guide the implementation of the design, and software architects being involved during UX concept design phases to give early technical input.

Change and constant improvement is most powerful when it's led from the bottom up, instead of imposed from the top down. Having a team from the front lines, who are involved day-to-day in projects, step back once a month helps us find, identify, and fix the root cause of issues instead of applying band-aids.

Working as ONE Team

Poor product designs are often the result of structural and process-oriented problems. Clients will often say, “The product manager presented a great-looking product concept, but the final product just didn’t live up.” or “Our developers are really frustrated with our designers. You guys aren’t going to give us a blue sky design are you?”

Avoid Functional and Geographical Silos

There are a number of underlying root causes for these problems. Here are a few we frequently encounter:

• Product management works with the design team at Global HQ, then ships the design offshore. Everyone crosses their fingers and hopes the finished product comes back as beautiful as the original design (hint: it won’t!).
• A single, understaffed design team (or in many cases, a single designer) within the organization serves all of the development teams. Naturally, the lone design team is swamped. Managers and developers lose faith that the design team can deliver and, as a result, begin to exclude designers from projects.
• An external design firm creates a design and “throws it over the wall” to your development team, never to be heard from again once engineering begins.

Leading product firms like Apple, Google and Facebook are much more integrated, because the silo-ed approach inevitably leads to problems. When a design team is pushed to work in a vacuum, the development team often ends up with a bunch of pretty pictures (in their words) and is left to interpret and fill in a lot of blanks. What does clicking on this button in the corner do? What happens when the user navigates back? What do we show when the app loses connectivity? How should controls resize and anchor on the screen when you pinch and zoom?

Part III - Staging the RIM Comeback

RIM's challenges are tall - no question about it. But there is still so much opportunity and the mobile pie is going to grow so much more. Earlier I talked about Step 1 in Part I - Staging the RIM Comeback and Step 2 in Part II - Staging the RIM Comeback Step #2 - Show the Love to the Carriers, Baby in staging RIM's comeback. Here I explore the last leg.