User Experience (UX) is the discipline responsible for delivering an optimal experience to the user of a product or service.
For decades, as Alan Cooper wrote in his seminal work The Inmates are Running the Asylum, we’ve endured functional but unappealing software products (especially in the enterprise) because we’ve allowed software engineers to design the experience.
Readers of this blog already know that I’ve written about the product manager vs product owner roles before.
This month, as an Aha! Ambassador, I have contributed a post on the topic that includes a breakdown of the duties of each of those roles.
Product teams exist to assess opportunity and capitalize.
Product managers are tasked with finding market problems that are pervasive within a certain target market, and that people are willing to pay to remedy. Then, once found, product owners guide the development of a profitable solution to those problems. (at smaller organizations, those may be the same person)
Market problems can be solved with new service offerings; new features; new partnerships; or new products. Given limited resources, however, product teams can’t pursue every opportunity. They must prioritize.
It’s hard for a product owner to keep perspective when looking at a stacked list of features needed in a product, much less communicate the high level roadmap to others. Backlogs are too granular and, frequently, just too long. Often they contain many capabilities that will never be delivered!
A product’s user stories may be broken up numerous ways: by very narrow slivers of end-to-end functionality, by seams in the technical architecture, or by some other approach.
What’s your product vision?
As a product leader, you already know that the most powerful way to align the independent teams you need — user experience, product marketing, sales, executives, etc. — without any authority is a compelling product vision.
Adam Nash refers to a strong product leader as a force multiplier. People respond if you paint an image of a place worth going, and a credible plan (your product roadmap) for getting there.
Product management teams have traditionally been responsible for delivering documents full of requirements. Market Requirements Documents (MRDs) define problems experienced by some segment(s) of the market as defined in an Opportunity Assessment, and Product Requirements Documents (PRDs) define the solution to be built.
Traditional software efforts–driven by project thinking rather than product thinking–have been notoriously unsuccessful. Many of the software efforts surveyed were internal technology projects, but commercial software products haven’t had a dramatically different outcome.
Have a product in customers’ hands?
Get ready for an unending river of feature requests! A common problem among product management professionals is how to handle requests from clients and prospects in various market segments, along with strategic initiatives. “They’re all good ideas!” Handling feature requests combines several distinct problems:
- Tracking requests, usually including the submitting party and the date.
- Identifying the underlying problem.
- Prioritizing the changes to the product.
- Designing and estimating the solution.
Product management professionals are always looking for a way to get to market faster. One common-sense way to do this is to build less prior to market launch. So what’s the least you can possibly build?