Too Tired to Blog? Nah…
So, I’m almost too tired to blog, but not really. Having been at CES for only two days, and with the show just getting kicked off tomorrow, it’s been a little bit crazy around these parts.
We’ve had a successful re-brand launch, something that I’m very, very proud of Rachel for putting together and executing so well on. Trust me, it’s not as easy thing to do. Also, putting together her first CES and having it be just freakin’ amazing is putting it lightly. She is keeping us all on our toes, and I can barely get the time to Twitter or record a video here and there.
I’m really looking forward to attending the It Won’t Stay in Vegas Blogger Party Tuesday night. Hopefully I’ll get to meet some very cool people there. Also, Rachel and I will be trying to get over to the Podtech Bloghaus this year at the Bellagio — we’ll see if our legs will carry us there after standing in the booth for 8 hours each day.
If you are in town and want to meet-up, drop me a line.
Seesmic Videos
Big thanks to Loic Le Meur for sending some Seemic invites my way. I’ll be posting some videos all through CES, and beyond…lucky you. Maybe even some on product management…who knows.
Here’s the first one — the rest will appear in my Twitter feed over to the right.
Maintain Your Focus
Here’s a great little bit from Manage It, by Johanna Rothman…this book is highly enlightening and it’s great to know I’m not the only person thinking some of these things.
I once worked for a company that decided aftear a several-day offsite strategy meeting that we were going to “focus on five.”
That isn’t focus.
Focus means to center all of the attention toward something. Five strategic areas are four too many.
Unfortunately, it’s all too common for companies to spread themselves too thin in order to be all things to all possible customers. If that’s the problem where you work, move to short iterations as quickly as possible so you can say to your management, “OK, we can start that next week, because we’ll be finishing this in two days.” Even better, make sure your iterations start and end in the middle of the week, such as a Wednesday. That way if your managers have “a-ha” ideas over the weekend, they’ll probably give you a couple of days to finish what you were doing.
Your team will thank you for maintaining focus.
Stay the course, folks.
If that course includes too much stuff, either strip some of the dead weight, or move on.
Product Release Plan
There is a great book called Manage It!, by Johanna Rothman. She does not disappoint, and really gets into the nitty gritty details about managing projects. While this is billed as a “project management” effort, it really does apply to product managers a great deal.
One of the things Johanna discusses early on is some of the tools she uses to define her projects - a project charter and a project release plan. While I believe both of these are valuable, I couldn’t stop hearing the “it’s just too much documentation” argument in my head. Would people refer to the charter for details, or the release plan? While I understand the difference on the majority of counts, I wouldn’t expect everyone to - even in the smallest of organizations.
So, I took what Johanna has detailed out as her two templates (the charter and release plan) and created a Product Release Plan template. Hopefully, this would become part of your PRD, and be refined as necessary for each release. There are some critical elements that are called out in the book that I have included, and they are pretty clear why.
That all being said, here is the template:
- Release Theme
- Release Requirements
- Release Criteria
- Release Goals
- Schedule Overview
- Risks
I’ll cover each of these points separately with a brief overview.
Release Theme
This should match to the release detailed on your roadmap. As I discussed in a previous post, creating theme-based roadmaps has a big advantage, and delivers a lot of clarity about a release without getting into “feature this” and “feature that” and scheduling.
Release Requirements
In her book, Johanna points out that each project should ideally have 1 driver, 2 constraints and 3 floats. The “driver” is what the project is absolutely dependent on - it’s the most critical thing. For example, it could be the release date, or the feature set, or a low number of defects.
A constraint is the second most important thing. The project isn’t 100% dependent on it, but it’s still pretty damn important. Floats are those items that you have more flexibility in managing. IE, stakeholders aren’t going to lose sleep if they aren’t delivered.
Release Criteria
These are the things that will mean the release is ready to ship. For example, is there a certain number of SEV-1 defects that need to be resolved? What about hitting a certain timeline? Maybe a specific set of features need to be met? Those points are all factored in there.
Release Goals
Goals are not requirements - they are items that would be ideally completed along with the release. For example, “making the performance of feature A 10x better than what the requirement states” or “adding a brand new set of smoke tests into the automated testing process of the product.”
These goals could be broken down into specific sections, such as product goals, team goals, project goals, and organizational goals. I’d stay away from trying to be too detailed here - especially on your first pass through a document such as this. It’s more important to get the key things down up front and make sure the team is executing and delivering on requirements first.
Schedule Overview
One of the methods Johanna states in her book for scheduling is called “top-down.” I prefer this method to all others, since it involves setting milestones first, and working out the details for each milestone from there. This is much more conducive to successfully planning releases from a roadmap, since the roadmap itself is a high-level set of milestones.
Jot down the milestone name and the estimated date for its completion in this section.
Risks
Risks can be difficult to identify clearly. However, they are very important to have and be aware of throughout development to ensure the proper mitigation actions can be taken. Within this section, identify each risk, the probability of it occurring, its severity if it did occur, the date at which you are most at risk for it causing problems, and the action being taken to resolve it.
I believe that most of these will be identified by the development team. However, because a product is much more than just code, if there is a marketing risk it should be identified here as well. For example, “a relationship with a PR firm may not be in place in time to get the press release done and out prior to the ship date.”
