Personal tools
Document Actions
Home / Resources / Webinars / Effective Agile Product Management Through Automation
Document Actions

Effective Agile Product Management Through Automation

with Christina Noren, VP of Product Management at Splunk

Sometimes it seems that agile development is an end run around effective product planning and market analysis. It also can undermine product positioning and roadmapping. Yet the benefits of a more responsive and productive product development team are too significant to ignore.

Learn how the Splunk product management team is automating the Pragmatic Marketing Framework to feed continuous market-driven priorities into an agile development process, and then leveraging this automation for continuous communication back to its user community, customers and field organization.

Watch "Effective Agile Product Management Through Automation"






About the Presenter

Christina NorenChristina is the voice of the customer at Splunk. With a unique approach to blending support and product management into a single team, she's built systems and processes to capture every Splunk user interaction - synthesizing them into interesting problems for engineering to solve. Her dream is that every engineer working on a feature can instantly connect with every customer who needs it.

Contact Christina at: cfrln@splunk.com

Question

Posted by Hendrik Bartel at 2008-11-21 08:54 PM
Where do you see the value of BD coming in during your process pre/post sales? Could you expand on using your CRM for PRD/MRD generation And how does BD fit into your process?

Clarifying question / partial answer

Posted by Christina Noren at 2008-11-24 03:09 AM
Depends on how you define BD - there's a lot of different definitions depending on profile of product/company/industry. For us BD is channel - OEM, distributors, 3rd party developers - they're customers also and their issues come to us using the same plumbing, and we use the same linkages to identify which partners and partner prospects we should talk to in order to clarify requirements.

On using our system for PRD generation - it's not our CRM but our engineering issue tracking system which clones enhancements from the CRM. Our PRD is a report of "problem statements" in pragmatic vernacular with linked inputs, features and requirements. The textual content is pulled from freeform description fields on the problem statements, features and requirements - the standard for content there is the same as it would be for a manually created document.

Tools

Posted by Melissa Downing at 2008-11-21 08:54 PM
What tools would you recommend for a software development company of appx 100 employees, 8k customers who is just introducing the position of a product manager for the first time. Where does one start? Information is everywhere in multiple databases. The basic tooling for a new PM position was my question.

Resistant to change

Posted by Milena Krasteva at 2008-11-21 08:54 PM
What if the engineering organization is resistant to changing requirements late in development because the overall quality always suffers and they are held accountable

keeping up with engineering

Posted by Mary Ann Fitzhugh at 2008-11-21 08:54 PM
How did you manage keeping up with engineering while you were putting this system in place? How does this system help you manage changes in requirements late in the process?

Question

Posted by Michael van Daelen at 2008-11-21 08:54 PM
Do PMs get dragged in to writing specs rather than writing requirements? Do PMs prioritize all bugs, or has R&D some freedom to use their best judgement?

reply to your question

Posted by Christina Noren at 2008-11-24 03:09 AM
The key to keeping the PMs from writing specs is to involve engineering leads from the point the problem is defined, and jointly develop the feature concept and associated requirements. Although we've gotten dragged into more the model is that PMs enter at most functional requirements, and only after a joint concept is understood, and engineering leads enter their own technical requirements and write feature technical specs that are linked from this system.

Re bugs, I didn't cover that much in the presentation but it's a separate process that is actually more support/QA driven with PM providing arbitration when there is dispute on the feature vs bug call, or in terms of tradeoff of developer priorities vs new features. Support is a much more active part of the extended product team here than most places.

Call Center

Posted by Chris Gorski at 2008-11-21 08:54 PM
Are call center issues tied into CRM system? What prompted the linkage with the CRM system?

answer to your question

Posted by Christina Noren at 2008-11-24 03:09 AM
The CRM system is used for tracking support issues, so that's the key tie-in. We also like being able to click back and forth between enhancement requests and profiles of current deployments and past opportunities so we have color around what kind of customers are the source of the requests. As we build out more structure in our deployment profiles on the CRM side this will become even more valuable.