Posts tagged Requirements
Internal systems
Aug 30th
One of the takeaways I’m finding in Bill Jensen’s book Simplicity is a reaction to the effect that information overload has on company productivity. As there is more and more information to process to do one’s job, it becomes ever more important for a company to provide tools that not only provide access to information, but which help interpret the information in the sense of analytics. So how does this manifest for a large company aiming to produce streamlined products for the marketplace, that will address (and solve well) a specific problem?
As a product manager with a multinational corporation, I find that (at least at my company in my specific division/subsidiary) there’s a contrast between the streamlined solutions we’re being asked to produce, and the cumbersome internal systems we use to collect and analyze the information we use to design such products. The systems we’re building are “push,” but the systems we use internally are “pull.” Some of this may be due to our company’s implementation of off-the-shelf requirements management and project management tools, but the net result is that the company does not make it easier to easily understand the decisions we need to make, much less make them.
I suspect we are not nearly the only ones.
One of the products I’m developing now is a service which can run client-server or on the web, in order to maximize the base of customers to whom we can provide a solution. I’m finding that questions about–and design of–the internal management components to be used by company support representatives are getting short-changed due to the pressure to meet release targets. This is certainly not unique to this one product, and the support angle hasn’t been ignored, but at the same time the support team’s “use cases” have not been considered with nearly as much diligence and interaction design as the product itself. So in one sense, the sub-optimal experience product managers have with requirements tools is being propagated to the experience support reps will have with service management.
Something I need to reiterate within my organization.
Interesting post about forgetting feature requests
Feb 27th
I ran across a blog post today suggesting that the work of tracking and logging feature requests is unnecessary. As the thought goes, the ideas that keep coming up are the ones worth considering anyway, so those repeated mentions serve to remind the product manager of the market’s needs.
I find this interesting in its minimalism, but within a large software organization it seems like this might be difficult. The product manager is often several levels removed from support calls, which is where a high volume of customer contact is made. The product manager’s site visits, interviews and observations may be only a small percentage of the company’s contact with its customers. So is it wise to trust that the product manager’s selection of contacts is wide enough that those same important ideas will bubble up to the top?
The degree to which a product manager spends time listening to the market also plays a part. If the product manager carries products all the way through commercialization, time in market may be sporadic or limited; in which case, this concept would seem to be more risky of not hearing the “right” messages from the market.
Still, interesting food for thought.
Product Managment should not be overburdened with Project Management
Feb 14th
As a product manager, after delivery of requirements to the development organization, I find myself spending significant amounts of time doing the marketing related tasks I expected to do, but even more time managing the development and QA effort to get the product to market. The role of product management is well known to be responsible for be delivering overviews of the product to the technical writers, trainers and sales people. What it is NOT known to be responsible for is the daily follow-up on defects reported by quality assurance, and the job of maintaining intense focus to “get things done” by the dates promised. I’ve also written about this before. Is this a frequent problem in the industry, or the sign of an immature organization?
Signs suggest this is common:
If the product management surveys are to be believed, most product managers spend very little time doing the things we know that we should be doing, and instead spend all our time managing logistics, and doing detailed work in marketing, development, or sales.
I am responsible for three products of highly varied scope and type. Each product, in order to be great, needs the dedicated attention of a product manager who spends time out in the market discovering the problems customers would pay to solve. I find that merely managing ONE product through the development cycle has severely limited my ability to interact with the market, to the detriment of the other two products for which I function as the market spokesperson. The organization continues to come to me for detailed information about not only high-level milestones but also low-level defects and test pass rates, so while I suspect I need to become better at time management, I also suspect that the organization just doesn’t “get” product management.
Reviewing Steve Johnson’s Pragmatic Marketing e-book on The Strategic Role of Product Management, I am struck by this extract:
For technology companies, particularly those with enterprise or B2B products, the product management job is very technical. This is why we see many product managers reporting to Development or Engineering. However, we’ve seen a shift away from this in recent years, from 19% in 2001 to 12% in 2008. The problem appears to be that technical product managers spend so much time writing requirements that they don’t have time to visit the market to better understand the problems their products are designed to solve. They spend so much time building products that they’re not equipped to help deliver them to the market.
In my organization, it’s not that I spend too much time writing more and more precise requirements–in fact, we avoid use cases so that customer requirements avoid stepping into design. However, our problem is that several high priority products are under the guidance of the same product manager, who cannot manage all of them well.
Does this strike a chord in your experience?
Text = Ambiguous
Jan 27th
Excuse the short post. One of the projects on my plate this week is an internal support system, from which requirements are being elicited from numerous potential users and business stakeholders throughout a number of segments of the company. The requirements that we’ve created are thorough to the point of potentially being unbuildable, because they support a number of ways of doing business that are in place in those various company segments.
The business is challenging the strategy of supporting all the ways of doing business, since stremalining them might lead to a better solution. The video featured here depicts the challenge of numerous stakeholders and business leaders in a realistic way, and thankfully I am able to state that we have delivered workflow diagrams to go along with the plentiful text-based requirements.
One of the things I’m trying to convince my team about is the advantage of delivering multiple types of models to provide several views of the requirements. To me, it makes the requirements more consumable than simple text or text plus one graphical view.
Enjoy!
Metrics
Dec 29th
I just ran across an interesting presentation on the use of metrics in product management by Dan Olsen, which shines some light on the art of convincing the business side of the organization of the value of a proposed solution. Though the metrics in the presentation are primarily website-related, including click-through rate and rate of registration for a site, the concepts are still applicable to all types of business cases.
Particularly insightful is the idea of graphing the ROI of various benefits in an attempt to illustrate the value proposition (slide 26). Those customer benefits which have the highest importance to the user, but which have the lowest current satisfaction rate, may be the ideal benefits to bring to the table first, or as labeled within the slide deck, “upside potential.”
Have a look!
