Automating and opening up product planning
| Posted: | September 15th, 2007 |
| Tags: | Splunk |
The PM and engineering teams are embarked on an interesting experiment here at Splunk. While we’ve always leveraged the support case system to track enhancement requests and automate some of the input end of the product management process, the real meat of product definition has happened pretty much as it does anywhere - via product requirements documents (PRDs) written by PMs and answered by a variety of technical specifications, bugs and tasks in the engineering tracking system, emails, whiteboard sessions, etc.
OK, it’s Splunk, so the PRDs and tech specs have always been on the corporate wiki so there’s some measure of collaboration. Anyone in the company could go up there and have a look at what was in progress. But it’s been pretty difficult to keep PRDs and specs fully up to date while we’ve been innovating as quickly as we have since the initial launch of the product in 2005. And it’s been impossible to give our customers and field sales engineering teams the level of transparency we want in order to get their full involvement.
Our public roadmap has to be created manually and is of necessity fairly high level and updated only every month or so. The other PMs and I are constantly fielding a barrage of “what’s the status of this feature?” questions.
Now that engineering is moving to a scrum-based model (read what my boss has to say about that) in order to deliver functionality quicker and more incrementally, the whole notion of a PRD is obsolete. But that doesn’t mean that product management is obsolete - in fact a rational process of analyzing inputs, setting priorities and communicating about new feature capabilities is more important than ever.
So the experiment: We’re hacking Jira, our bug tracking system, in order to automate the entire product planning and marketing process and facilitate real-time communication back to customers, internal stakeholders and even the community at large via our public roadmap.
We’re leveraging Jira’s capabilities to create custom issues and workflows in order to reproduce the essentials of pragmatic marketing’s “requirements that work” framework, the bible on effective product management. (I wish I could link to their picture but unfortunately they are so busy selling seminars the information is under lock and key.)
This means that we setting it up to automatically bring enhancement requests from our SugarCRM system into a PM work queue within Jira; asking PMs to enter call reports and market datapoints; linking all of these to problem statements; and generating granular engineeringrequirements from these problem statements. These requirements then get triaged by the cross-functional scrum teams into sprints to deliver small, complete units of functionality quickly. Features are entered as the requirements get into enough focus in order to describe complete pieces of functionality and their benefit to customers.
Beyond “requirements that work” planning, we’re going to be driving a lot of the outbound communication off this system as well. For example, when a feature’s last critical requirements are completed, we’ll be automatically opening a task for a product manager to create a demo for the feature, another to update the datasheet, etc.What’s most exciting is that once the system is tuned and we know it’s producing accurate information, we’re going to be able to give customers and the community real-time status and with the ability to give input right in the middle of the design process. Customers with enhancement requests tracked through the support portal will be able to see how they’ve been triaged, how the problem has been interpreted, and what requirements are at what stage of delivery to meet the request.The public roadmap will be maintained in real time, with the potential for drilldown into more of what’s behind each listed feature.
We’re not the only ones trying to marry agile/ scrum with pragmatic marketing. FeaturePlan is a great dedicated product for product managers that does just that. We looked at it and like it but unfortunately it’s currently Windows centric in the software version while our current internal corporate infrastructure is pretty Linux-centric, and we’re too oriented around running our own systems to use their hosted version. (Here’s a good presentation by Jason Tanner that describes using FeaturePlan in a similar way.)But I think that the level to which we’re trying to open things up to customers and the community is new ground.
My intent is to post here as we progress with this experiment as a way of tracking our progress and forcing myself to think through some of the challenges.
If you’re trying to do something similar at your company, I’d love to hear from you. I’m happy to share some of our process flows and schemas for Jira as well. Just drop me a line at cfrln@splunk.com.
- Posted by cfrln
September 15th, 2007 at 10:14 pm
The Pragmatic Marketing Framework you mention is available for viewing online. Just check out http://www.pragmaticmarketing.com/pragmatic-marketing-framework or http://www.pragmaticmarketing.com/pdf/PragmaticMarketingFramework.pdf.
September 16th, 2007 at 12:42 pm
Thanks for pointing out our oversight at not having the Requirements That Work graphic available to our community. Here’s the link (it’s at the bottom of the page).
http://www.pragmaticmarketing.com/seminars/requirements-that-work
It’s always great to see how companies are implementing what we teach.
Barbara Nelson
Instructor
Pragmatic Marketing
September 16th, 2007 at 2:02 pm
Hi Barbara,
Thanks for posting the link - I’ve often found myself wanting to sendout the graphic as a link.
September 18th, 2007 at 1:00 pm
Hi,
I’m a product manager at a smaller-sized shop (~100 people), and we’ve implemented both Pragmatic Marketing and Scrum over the last few years. We just recently started using JIRA for both of those efforts, with some success and some wishlists.
On the positive side, JIRA has helped us with maintain the scrum backlog quite a bit. I can easily keep track of all the issues we’ve scheduled for release, mapping those issues to a particular sprint, and keep our product roadmap relatively clean. We aren’t losing enhancement requests nearly as often as we used to on the backlog spreadsheet.
The problem in using JIRA is that it doesn’t cover the rest of the market datapoints as you described in your post (call logs, problem statements, win/loss reports, etc.). It is only strong enough to help with the enhancement requests and product defects tracking, so those other things all have to live somewhere else.
To tackle the market analysis task, we looked at FeaturePlan, but we felt it was sorely lacking in support of a Scrum development methodology, so it wouldn’t work well for us. Instead, we started using JIRA in combination with another Atlassian tool, Confluence, to help us organize the market data. I think my boss would have preferred a tool that isn’t quite as wide open as a wiki, but we’re making it work.
I think the ultimate solution would add more market analysis support in JIRA. Instead of just picking a customer’s name in a multi-select, I should be able to create a full-fledged customer record and assign that record to a market segment. I could then coordinate lists of issues not just by customer, but by an entire segment of customers looking for similar functionality. Right now, the best we can do with JIRA is to label each individual request with that type of market information. Tedious at best.
Patrick Masi
Product Manager
Sircon Corporation
September 18th, 2007 at 1:05 pm
We’re solving that through a combo of custom issue types for market datapoints (catch all for now for win/loss, competitive research etc.), call reports and enhancement requests, then just implementing links back to our CRM system for the account detail. I’m trying not to duplicate the account record in jira but just bring over what’ s most relevant and be able to report across them.
I’ll probably post my schemas and workflows for these custom issue types soon.
September 18th, 2007 at 2:37 pm
We tried to use issue trackers on Scrum projects, but it was quite difficult. So we started to develop our own solution from scratch. We’ve showed Savila to a number of other developers and the reaction was quite positive. Currently we are looking for more input and I would like to get in touch with people who want to have a closer look: sns@caimito.net
September 18th, 2007 at 4:07 pm
For those using Scrum with JIRA, have you tried GreenHopper?
http://www.greenpeppersoftware.com/en/products/GreenHopper/
It provides task boards, planning boards, drag and drop story reorganisation, burn down charts etc. I’ve heard good things from other customers, might be worth a look.
Otherwise, try the labels plugin:
http://blogs.atlassian.com/developer/2007/09/jira_labels_plugin_20_1.html
As this allows you to to all sorts of useful arbitrary issue categorisation, and with a slightly ‘organise’ label scheme, you can fit a lot of organisational processes into it.
Hope this helps - great post!
m
September 20th, 2007 at 4:19 am
[…] Cfrln » Blog Archive » Automating and opening up product planning Get Splunk Splunk.com | Splunk Base | Splunk Blogs […]
September 20th, 2007 at 5:40 am
Hi Christina,
It seems our open source product Yoxel Systems could help you
with supporting agile methodologies and iteration planning process.
Check out this recent issue of o3 magazine:
http://www.o3magazine.com/pastissues/issue7/
Best regards,
Alexey
September 21st, 2007 at 5:44 am
Hi Cristina,
We too are implementing agile/Scrum and are JIRA and Confluence users.
I would love to see any specifics around your extensions to JIRA. Workflows, schemes, etc. would be awesome. We are just beginning to build out the product side of our agile so the timing of your blog was great!
Amanda
October 24th, 2007 at 6:48 pm
Fantastic post and timely for some things I have been considering. We use JIRA and Confluence and our products are based on apache open source projects which are by definition driven by the community not by a single company or PM. I have been “classically trained” as a PM via Pragmatic Marketing, and I am looking at ways we can enhance our productization model. I look forward to hearing more about your workflows etc and would love to chat by phone or email as well. Thanks for sharing.
December 17th, 2007 at 12:25 pm
[…] 17, 2007 Here is an interesting post by Barbara Nelson, Automating and opening up product planning. Yet another example of a team trying to hack and integrate a few existing tools to build a […]
January 2nd, 2008 at 1:34 pm
We are using JIRA to handle product management completely. As a smaller company (~150 people), we have found that as soon as we write requirements they are out of date so we took a completely dynamic approach and JIRA is what enables this. We also handle customer complaints in JIRA allowing for issue linking easily.
We spent the time to define the “just good enough” (I believe this is an XP term) steps for a product release and are importing them all into JIRA with each product release, minimizing startup energy spent. Our products are both mechanical and software, in some cases, both. Our process allows us to keep the product team accountable for all the things we know we need to get done for a release while being flexible enough to allow for changes up to the last moment (you all know you have them!) Custom reports and release templates we created allow for on-the-fly documentation. As the project changes, so does the documentation! No need to manage documentation separately.
January 2nd, 2008 at 1:36 pm
We are using JIRA to handle product management completely. As a smaller company (~150 people), we have found that as soon as we write requirements they are out of date so we took a completely dynamic approach and JIRA is what enables this. We also handle customer complaints in JIRA allowing for issue linking easily.
We spent the time to define the “just good enough” (I believe this is an XP term) steps for a product release and are importing them all into JIRA with each product release, minimizing startup energy spent. Our products are both mechanical and software, in some cases, both. Our process allows us to keep the product team accountable for all the things we know we need to get done for a release while being flexible enough to allow for changes up to the last moment (you all know you have them!) Custom reports and release templates we created allow for on-the-fly documentation. As the project changes, so does the documentation! No need to manage documentation separately.
January 20th, 2008 at 3:38 pm
[…] few months ago I wrote about our effort to automate and open up product planning by implementing a process around distilling product inputs into requirements using Jira in support […]
May 5th, 2008 at 12:14 pm
What they said:
What they meant:
“If you knew this person as well as I know him, you would think as much
of him as I do.”
(Or as little, to phrase it slightly more accurately.)
“Her input was always critical.”
(She never had a good word to say.)
“I have no doubt about his capability to do good work.”
(And it’s nonexistent.)
“This candidate would lend balance to a department like yours, which
already has so many outstanding members.”
(Unless you already have a moron.)
“His presentation to my seminar last semester was truly remarkable:
one unbelievable result after another.”
(And we didn’t believe them, either.)
“She is quite uniform in her approach to any function you may assign her.”
(In fact, to life in general…)
—————————————————————————————————-
http://adelinefordqe.easyjournal.com
May 9th, 2008 at 3:29 am
a445f9c2a14b
a445f9c2a14b384f99ea