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.”
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.
Brief Notes on Scheduling
Dev scheduling, and scheduling in general, plays quite a big part in my day-to-day work. Everyone comes to me for dates, estimates, status, release details, etc…
So, how does one go about it in a startup without going totally crazy? Well, by avoiding getting sucked in to the details, of course.
I’m really all about macro-level views. I like to keep things fairly hands-off, but know enough about what’s going on that I can provide guidance / assistance when required. The other benefit to doing things this way is, you can handle a lot more because you aren’t trying to manage all of the sub-tasks that sit below a milestone, but you can start to drive communication / efficiencies cross-functionally, which is also a big part of being a successful PM.
There’s an underlying theme with this that I’ve been told a few times by people way smarter than I’ll ever be: if you control the information, you have some degree of influence. I still have to think about everyone creating and sync’ing schedules and how to manage that in the sense of getting folks the right information in a timely manner - helping them execute where I can, and actually executing on your own stuff.
Part of the fun in all this is that no one group in an organization will handle schedules the same way. But of course, a PM needs to get team leads / project leads that are working on release-specifics, on the same page so it can all come together.
It’s a lot of fun, to be sure.
