Agile Product Strategy, Marketing, ProductCamp and more.
RT @celia: (via @StephenFleming) Steve Blank: "The golden age of Silicon valley is over..." m.theatlantic.com/business/archi… @sgblank
Requirements
So many products, so few gems
1488 days
The pace of technology innovation is unabated, even growing, and yet it’s commonplace to see new products released that don’t resonate. Either the products are good but are poorly marketed to their target buyers, or they are not solving a real market problem. I believe this signifies a need for better product management in technology companies.
Jim Holland speaks to this in his recent On Product Management post, A Product Leader’s Perspective of CES [the Consumer Electronics Show]. In it, Jim summarizes the situation:
It’s a shame really. You know the products. Ones that were designed and developed because they COULD, not because they SHOULD.
Jim cites a previous post I’d written in which I proposed four artifacts that a product manager can use to define a proposed product:
- The problem being solved
- Buyer and User Personas
- Value Proposition
- Solution Workflows
In an agile or scrum environment, it may only be the core workflows – much of the finer detail and other workflows may be emergent. But the basic workflows must be in mind, or there isn’t enough definition around what is to be constructed.
I propose that if the product manager or product owner can confidently communicate these four items, he is on the way to delivering something of value to the market. The challenge is to clearly identify these items before building the product — and if they can’t be identified, this is a golden opportunity to avoid investment in a product that will become one of the many developed just because someone could.
Internal systems
0992 days
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.
Text = Ambiguous
01207 days
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!
Documenting Requirements
11238 days
by johnp
in Requirements
The language of requirements is a challenge to explain: there is an art involved in writing declarative statements that specify what needs to happen without inadvertently limiting the implementation. Certainly, the choice of words is important: words like “select” and “supply” are more vague than “click the radio button for” and “type into the text box,” but there’s more to it. I’ll elaborate on that in a future post.
I continue to be more convinced that multiple methods of delivering requirements are needed to draw a complete picture. So even though one might have the language challenge under control, various types of models (both graphical and verbose) can help to provide views into the system’s requirements from all sides. But how do they relate to each other, and how do the models relate to the declarative statements that provide the granular detail of what is needed?
The methodology I’ve seen implemented most frequently, when boiled down to brass tacks, is just interviewing and observing users and identifying requirements, and then backing them up with more intricate system models. The more I reflect, however, I think there may be a smarter way. One approach I’ve seen from a few sources is to depict the system’s primary uses in the form of use cases, which can be further broken down into any number of scenarios that depict the use case with specific input values and paths through the use case; and then, writing requirements that support each use case. One point made in a highly recommended article at TechTarget.com is: requirements that don’t tie back to a use case may be a warning sign of missing use cases. Working through a deliberate methodology like this might be a step towards preventing any significant gaps in requirements capture.
The above article from TechTarget also considers data elements, and recommends entity-relationship diagrams to zero in on the data elements. As a product manager, I see that fitting in a little deeper into the cycle at the business analysis/design stage, not at the customer requirements/analysis stage. What do you think?
Non-Functional Requirements as Stories
01266 days
by johnp
in Requirements
In a prior post, I suggested that the use of a thorough checklist of possible non-functional requirements categories is a good way to probe for the relevant requirements on a specific project under consideration. As I think about it now, I realize it may also help to review non-functional requirements of other projects as another source of inspiration.
My point for writing today, however, is the idea that regardless of how one arrives at those requirements, one can still use the user-story format for recording them. Particularly when the requirement is a business-level or business-driven requirement rather than a customer-driven one, this format allows the recording of the source of a requirement so that it is easier to explain and remember later:
Consider the example of the CTO constraining the team to use the existing orders database. (This was the real situation; the team was considering a second orders database that would be sychronized at night. The CTO overheard this and said “no!”) If we wrote this requirement as simply “Must use existing orders database” it would be entirely possible that a few months down the road we wouldn’t remember why we should be constrained in that way. We’d ask the product owner if she cared if we used a secondary database, and she’d say she had no objections. And we’d make a mistake of using one. Embedding the person who wants something can be very useful.
In my own experience with collecting and then analyzing requirements for several active projects (Each at a different phase of development) I have run into the problem of not remembering the source of requirements at a later date. The author also suggests thinking of them as “constraints,” rather than “non-functional requirements” — which is a suggestion the linguist in me finds appealing, as it is a more naturally meaningful phrase.
While the CIO suggestion above does illustrate the way I find the user story format to help solve the requirement-source problem, I have a related problem that I have yet to solve: remembering the details of a negotiation. Over time, different stakeholders may make differing or even competing requests. Later in deelopment, when these stakeholders ask why their suggestion was not accepted and implemented, I have a hard time remembering the rationale for a particular decision. Thoughts, anyone?
The Economic Downturn
01302 days
by johnp
in Requirements
What impact does the economic downturn have on your enterprise, and on the products you manage? The answer to that, truthfully, is unknown.
The product manager, as representative of the market, may be the role best suited to finding out what the market’s changes mean to your products. Calling customers to find out what effect the market’s turmoil has on their budgets and their short and intermediate term plans is probably a wise idea for all businesses, and the answers can only help to reduce the uncertainty.
What you do with the information is, of course, up to you and depends on the product and market. But don’t go unarmed into a battle of information.
Start with the Problem Statement
11302 days
by johnp
in Requirements
For all the talk about bad products and poorly designed features, many companies don’t spend enough time listening to the market. Some think they do, but they listen passively and only hear feature requests. What really helps drive a great product is to listen actively and hear problems.
Working within the problem-solution paradigm inherently demands that we accurately understand what the problems are. If we start from the incorrect starting point, following the correct path to a solution will cause us to solve the wrong problem.
This interesting article goes into linguistics and considers not just the language of problem statements in terms of the words we choose to write them in, but from the broader perspective of the framework in which we think about them. Abstracting the problem to the correct level is essential in solving the problem, which is what we are all trying to do.
Agile Modeling
31302 days
by johnp
in Requirements
One of the challenges I encounter with producing customer requirements for consumption by a development team is overcoming the barrier of understanding. My company does not have dedicated business analysts, so the role of translating customer needs to development needs and architecture is typically handled by our developers. What if they don’t see the big picture of what the user wants, but instead only see a large collection of unrelated detail?
Organizing requirments in categories can help to provide a mental framework, but navigation becomes difficult past 2-3 levels. It’s becoming apparent to me that in order to bridge the gap, some diagramming and coalescing of requirements into pictoral form must be provided. The question is, of the tens of possible types of models, which types are most effective and therefore worth the time?
I’ve found a site that details numerous types of models and diagrams, and provides handwritten examples of each. The silver-bullet takeway from this site is the following:
“know a wide variety of modeling techniques … apply the right artifact(s) for the situation at hand.”
My current problem is that I’ve been away from my brief studies in UML during my Master’s program for six years, and I don’t have command of that wide variety of modeling techniques. I have, therefore, just shared with you the newest item on my personal to-do list…
Recent Comments