Requirements Archives | The PM VisionThe PM Vision

Josh Duncan’s Podcast on Agile Product Management

03. June 2012 · 1 comment · Categories: Agile, Product Management · Tags: Agile, Product Management, Requirements, scrum

For those of you currently practicing agile product management, product ownership or both, there’s a great new episode of Joshua Duncan’s Start with the Customer Podcast that you should take some time to listen to.

Before I go any further, all of the episodes in Josh’s product marketing podcast are worth listening to! That said, this one is particularly of interest to agilists, as it features two well-spoken and outspoken leaders in the field. Scott Sehlhorst, who blogs at Tyner Blain, and Saeed Khan, who blogs at On Product Management, are both seasoned product managers who have both worked with agile engineering teams, and have also applied agile concepts and framework to the work of product management. In this podcast, the difference between those two models of “agile product management” is explored, along with several other topics agile , including:

- Saeed’s reminder that “product management has always been agile!” – it’s development who are finally catching up. Saeed also staunchly defends the need for product managers to continue to do the large segment of product management work that does not involve engineering–much of which is not accounted for in the typical definition and implementation of the “product owner” role.

- Scott’s reminder that while the tactical approach to solving a problem may change more frequently, the larger strategy–which he crisply defines as addressing a specific set of problems for a specific subset of customers, in a specific target market–doesn’t.

Thanks, guys, for the enlightening discussion! Have a listen today.

Thoughts on the How

20. October 2009 · 2 comments · Categories: Agile · Tags: Agile, Product Management, Requirements, User Experience, user stories, wireframes, workflow

Before I begin, I’ll issue a warning: What you are about to read is not advisable, though it is a first-hand account. (Also, I wish to credit Scott Sehlhorst for inspiring my commentary by his comment about this topic in this post about agile prioritization.)

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.

Internal systems

30. August 2009 · Write a comment · Categories: Product Management · Tags: interaction design, internal systems, Product Management, project management, Requirements, simplicity

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.