I’m currently running a large development project which is transitioning at the 2/3 mark from waterfall to agile.

Now that I have that out of the way, a little background.  The project was defined in terms of discrete requirements, originally tied together with a few key workflows and wireframes, and involves an n-tier architecture with a number of moving parts.  Though much of the underlying architecture was completed, we weren’t clear enough about the workflows and stories and the project was not producing tangible results fast enough.  So, while we recognize we should have started with agile, the company hadn’t adopted the agile methodology at inception.  To achieve our goal of better predictability and periodic peer review of the software, after it became possible in the corporate environment, we moved to agile.

Note that in the first half of the project, we erred on the side of providing requirements that stopped at the “what,” rather than providing the team enough about the “how.”  The move to agile has exposed that we weren’t providing enough context around each requirement (story) to enable the development team to build the product.  In this case, the complexity of the project and an unfortunate number of unknowns has made it useful for product management to collaborate with user experience well before presenting user stories to the development team, as advocated by others, rather than attempting to involve UX on an “as-needed” basis for each story.  In prior attempts to provide only the agile user story in “As a ___, I need ___ so ____” format, it quickly became apparent that the story wasn’t nearly enough.  We had to deliver the agile user story with the workflow steps (including interaction design) — only that seemed to eliminate enough uncertainty to proceed.

From a higher level, there’s another lesson here that operating under both paradigms has exposed.  It was quickly clear that for a complex system, providing the complete user stories and supporting material (including workflow steps, interaction design and wireframes) enables undesrstanding and fast action.   Though it was in some ways coincidental that we had wireframes before our sprints kicked off, it already appears to have sped things up significantly.

Hopefully the ramp-up will expand as we continue down this path, and we’ll reach the finish line quicker than we might have otherwise.

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.

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.

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?

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!

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!

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?

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?

While asking some stakeholders will only produce a range of “must have” to “really must have,” a more appropriate set of prioritization values is the MoSCoW method:

• Must Have
• Should Have
• Could Have
• Would Be Nice But Probably Won’t

The trick, it seems to me based on a curory explanation of this method, is determining which requirements to categorize at what value: and according to whom.  The person providing a requirement is likely to argue for its significance, so perhaps a method of evaluating that allows for quantification of the percentage of the user base affected (or which personas) may be of use.

Stay tuned…

A product manager is responsible for the marketing strategy, direction and features of a product throughout its lifespan.  A project manager is responsible for the success and progress of a project on behalf of the project sponsor.  The confusion in part can be alleviated by confirming that project != product. A product by definition lives beyond individual versions; whereas in most organizations, a specific version of a product is a project.  This is articulated in more detail at How To Be a Good Product Manager:

Project managers are responsible for the successful delivery of a project — a one-time endeavor with a goal, scope, deadline, budget, and other constraints. A project manager will work to align resources, manage issues and risks, and basically coordinate all of the various elements necessary to complete the project. As they relate to products, projects can be undertaken to build a product, to add new features to a product, or create new versions or extensions of a product. When the project is complete, the project manager will usually move move to a new project, which may be related to a different product.

Product managers are responsible for the overall and ongoing success of a product. Once the project to build the product is complete and the project manager has moved on, the product manager remains to manage the product through the entire lifecycle. Other projects related to the product may be initiated, with the product manager being the one constant stream throughout, defining the project goals and guiding the team to accomplish the business objectives that have been defined.

As a product moves through its life cycle, changes are often conceived and added to the project roadmap.  The product manager, interested in delivering the very best product to the consumer, is an advocate of adding features that will make the product better or fix oversights regardless of the schedule.  The project manager, on the other hand, is interested in specifying an agreed-upon set of requirements and working towards their completion within budget and on schedule.  These interests are inherently in conflict.

The answer?  In my view, the project manager should be provided a list of stories or requirements for a release (or scrum) that are prioritized by the product manager, so that the project manager has the authority and the knowledge to add and remove stories/requirements as needed in order to come in close to deadline and budget–after all, everything will NOT go as planned, and not all of them will be done on time.  What isn’t handled in release 1 is simply held over or deferred for release 2.

In theory, over the course of several releases, as the product is able to meet more and more of the original set of requirements, that product has the chance to succeed in the marketplace.