Breaking into a Sprint
I just stepped through a session planning out the next couple of iterations on a product halo with a colleague of mine. The process we have taken to using is quite cool. I don’t proclaim it to be unique in any sense of the word, but definitely something I’m liking the feel of, and one I could see really developing and growing with the organization.
I started by writing out a set of bullet points, broken in to feature groups on the white board. This was our baseline. We talked through each point, made some revisions, removed some, added some others, and proceeded forward. This really allowed us to reset, and get in to what it was we were trying to accomplish.
We then proceeded to prioritize each bullet point. Since we have a lack of customer data, and some things are just obvious (especially when dealing with halo items), it was pretty easy to go through and assign low / med / high or 1 / 2 / 3 to each bullet we had written up there.
After the bullets were all prioritized, we then assigned gross hourly estimates to them - nothing under 2 hours allowed. Since the bullets weren’t full requirements, this kept things padded to a reasonable amount, allowing us to continue marching towards to goal (yes, details on what exactly what is forthcoming).
We then decided, right or wrong, that since these are halo items and not product “features” in the true definition of the word, we didn’t need to rev the version number at all, really. So it was just a matter of adding up all the gross estimates and then identifying sprint length and doing some simple division.
So, we landed on each sprint being 10 days in length for the project. With all the tasks grossly estimated, this ended up being something like 9 sprints total. We backlogged a few things, but couldn’t really get that gross-level estimate to budget too far, so we stuck with it.
My colleague now has the lucky job of fleshing out those bullets in VersionOne and assigning them to the correct sprints. And then of course, gathering up all of the materials that do already exist and attaching them to the right items, and then proceeding to execute on some key market research tasks that were identified.
Yeah, I guess I’ll help out at some point.
So, what did we end-up with? Well, a pretty common thing - a set of requirements, associated to a release project and sprints in our requirements / product management tool (VersionOne). “Big deal” you say? Well, it’s important to recognize that when you have a crap load of things to do (especially halo items, which can be convoluted), using a framework / brief / flexible process that helps get all that stuff that’s currently up in your head down on paper and in front of others, can be a huge weight off your shoulders.
Keep tweaking, keeping writing things down - but when you find you have it all up in your head, take a step back, get some people in the same room as you and start to write out bullet points and take it from there. Worst case you end-up with an empty head and an eased mind. Best case, you have developed a quick and dirty roadmap for the next several weeks that can be iterated on.
Some Agile Development Commentary
I’ve written several posts in the past regarding agile development and how we’re leveraging some of it’s benefits internally at the present time. There is a solid post up at Tyner Blain, in which Scott provides some good feedback on a post written by fellow blogger Mishkin Berteig.
There’s a story a friend of mine (who works within a very large organization as a project manager) shared with me a while back. He was sitting in a meeting with a client and his top project team. A piece of QA within the release process for their code had broken down their process, preventing them from essentially, getting shit done.
That’s generally bad.
My good friend recognized something very critical though - why was backend regression testing (the piece of QA in question) occurring for the UX component of the software? They had nothing to do with one another, but were on the schedule and continued to be done.
The response from those around the table was basically, “that’s just how we do things.” Yikes! That answer, right there, can sum up a lot of what’s wrong within long, severely drawn-out release cycles.
We’re trying to get a v1.0 out the door, and will probably end up doing so this week. Now, we’ve been working on this (from the ground up) for the last, say, 2 1/2 months. That’s an incredibly short period of time to a) define a product b) get it through a development cycle c) market it, and d) release it. If, at any time, my response to a question had been, “that’s just the way it’s done” and thus prevented us from completing a key piece of the PDLC faster, I’d have expected I’d be fired partway through the process.
These types of excuses can be directly tied back to a few things:
- Egos - people want to cover their own asses
- Straight-up stupidity and fear - people don’t understand their role / job and are afraid to say, “I don’t know”
- Fear imposed by higher-ups - VPs and directors with no clue and way too much leeway to say, “my way or the high way”
- Silo’d, non product-centric organizations - those that define the company around roles instead of products
That last one is very important and one I remember touching on before. Agility isn’t just about having senior-level developers you can trust with flexible requirements, but it’s about everyone caring and contributing to the products themselves.
Who cares if someone is “in marketing” or “in legal?” Why does that matter? Their sole function is to solve pain for your customers and build great product. That’s why it’s so critical to commit to product management and not make it a half-assed effort just because everyone else is doing it. Get them in the center to do what they do - ensure the planning is place and crap makes sense, and then execute.
I digressed quite a bit, and it’s got nothing to do with how Scott’s post is written. The difference between using waterfall and using agile approaches is very simple - at least in my mind. If you have a complex, workflow-intensive product (like a banking or insurance-level application), you should be planning your PDLC’s using waterfall methods. If not, plan your whole PDLC using agile. No question.
Of course, that’s not to say, product groups within the overall (probably silo’d) organization that make up the individual feature teams or “product” teams if your suite is broken down that way (a la Microsoft) can’t use agile. They should. It would probably help them work faster and more closely together.
Sorry, Scott — I started out by intending to respond to some of your key points, but kinda got off on a tangent.
Locating Market Data
I have been spending a bunch of time heads-down, analyzing market data. This is a key part in any PM’s life, and this magical data can really come from anywhere. Here are a few of my favorite sources:
- Sales pipeline
- Support
- Win / Loss
I thought I’d jot down some of my thoughts on each of these different areas that can lead a PM to helping create a better product. But first, I want to get something out of the way: gathering market data is NOT (I repeat) NOT, a one-time process, or something that happens once every six months. You should be devoting at least some fixed percentage of your time each week to doing market research.
Remember, a PM serves as the proxy between the company and its customers / market. No questions asked.
OK, with that out of the way, on to the post.
Sales Pipeline
The sales pipeline is filled with wonderful little tidbits you can pull out. Generally, dividing a pipeline into broad strokes (beginning, middle, end type stuff) is the easiest way to go. This should give a good picture of where many of the deals are - whe combined with win / loss, this should present some strong collective feedback.
Support
Within our organization, support and QA both work within product management. I did this very deliberately: 1) support gets ingrained into them how to turn support inquiries / client deployments into helpful defect reports and feature enhancements without really having to get services involved. The second (the QA part) - it’s easier to keep a tighter lock on release cycles.
Each week, support produces a quick report giving key metrics about what clients are looking for. However, a PM does not have to turn these into requirements - as mentioned already, support is trained to do that themselves.
Win / Loss
Another key element to getting PM involved in the sales cycle — gathering win / loss data. I usually do this by setting up a custom form on the opportunity / lead list within the CRM system in use. This type of thing should be kept short and sweet. You don’t want to get crap from Sales directors / VPs that you are wasting their reps time filling out forms.
There are other channels where market data is gathered that I’ll pick up in another post. These are the core areas I’m using now, along with your typical prospect interviews. It’s one of my favorite aspects of the job; especially when it starts being a tangible effort that has a positive effect on the product development lifecycle.
Roadmaps & Communication
I like creating roadmaps. Maybe it’s because I like planning to much.
There’s just something so rewarding to me about charting out where a product / products are going for the next couple of month / quarters. Now that we are closing in on the end of the year, I’m taking some steps back and evaluating where some things are going to go. It’s a fun exercise.
However, at the end of the day, even thought I love creating and sharing this type of stuff because it gets me excited, I’m still cautious to make sure that right knowledge is communicated in the right way to the appropriate people.
In a start-up, your plan will be one thing one day and something completely different the next. This is what makes them cool and exciting, but it can make product management quite difficult, since much of the job relies on working within the market & with customers and charting priorities based on the data you gather.
But, in start-up land you can’t ignore innovation & ideas - especially when you have fast release cycles, or lack of market data due to lack of users. I’ve found a good method when it comes to roadmapping in an environment like this is to write things out the way you would regardless, even if you know some thing will change tomorrow.
Doing it this way ensures that you have your head around where you want to take the product, and then you can present more easily to management, and others.
Back to the point on communication — much of what a product manager is dealing with is in unformed thoughts, especially when working with 4+ products. It’s not a matter of “hiding” data or information from people. A lot of PM’s will phrase things this way - especially when talking about Sales. I used to as well, but seem to be turning some kind of corner in my head.
The way I’m thinking about it is, everyone needs to eventually get the stuff you are working on, but it’s up to the PM to decide how that stuff is distributed most effectively for the team. This means that it’s not effective or productive to talk to Marketing about how long a feature you’re thinking about will take simply because that’s the realm of development. To follow that example though, it’s only when you know how long that feature will take AND how it relates to the larger product plan does it affect product marketing plans.
In the same token, Sales is not affected by things like, “we’re shooting to release 1.5 on the 15th of January” when it’s only February of the preceding year. Arguably, no one is affected by that type of information. However, it helps me to plan that way so I can see where things sit on a calendar and if we are crunching too much into too little time.
Again, to follow that example through, Sales would find information more valuable in the form of, “we’re looking to release 1.5 in Q1 of 07″ — and then when it gets down closer, you drop another layer of, “end of January”, and then eventually, “January 15th.” However, in a start-up environment, v1.5 probably wouldn’t be seen at all, as the product could be dropped halfway through a dev cycle to work on v1.0 of something else entirely.
Again, this is what makes them great.
This isn’t HIDING detail or information. This is forming a thought in as complete a way as possible. To me, this is centrally important especially when it comes to planning and strategizing. It’s much more effective to discuss a strategy or a roadmap once it’s fully formed in your head.
Share things with those that are working on it / contributing to it directly, because “slam dunks” are bad too, but everyone is going to benefit from having something more fully formed than they will getting tidbits of half-assed / half-worked thoughts.
