Don’t Get Discouraged
When you are in the thick of things, it’s easy to lose sight of the bigger picture. That picture may be 1 month, 3 months, or 6 months (plus!) away, but people (myself included) can get wrapped up in not being perfect, seemingly not doing enough, or thinking you are doing things wrong.
You can’t get worried. Well, you can - if you don’t have certain key things in place.
It’s easy to get all down and razzled if you see constant new “competition” popping up all over the place every week, or other products getting press yours isn’t. Quite frankly, it’s just not worth it. Take it as inspiration, learn what you can from it, and press on.
Remember - it comes down to a couple of things. Are you solving a problem people have, and does your product add some good value while solving it? If everything from the top-down (I’m not talking organizationally, really) is aligned, that means you have placed your bets and can just worry about execution.
It’s all about placing a bet and executing. “Wow” features and “silver bullets” are not what you rely on to build successful products. It’s all in the fundamentals. Those things may come along, or maybe you are developing one without even realizing it - but you can’t hold things up waiting for those ideas to come along.
You need to just do a few things really well. In fact, things I’ve already mentioned:
- Ensure you are solving a problem
- Align things form top to bottom
- Execute — quickly and with confidence
This “top-down” stuff I speak of is from the vision / problem identification, to the roadmap, to the requirements, to each release being pushed out the door. There are a few strategies that go into shipping a product which I may detail in other posts (for example, is this product brand new? does it already exist? at what stage of the lifecycle is it?), but for now take solace in having a clear vision to which all decisions are baselined.
If you are focused on something (almost obsessively so) you are doing everything right. Of course the organization could fail - but all you can do is pick a problem and go after it as hard as you can. You can’t solve all of the World’s problems by building 15-20 products at once.
Remember — it’s all about being good enough. Well, in most cases. Tony Stark may have a problem doing that, but start-ups building Web applications should not.
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.”
Product Roadmaps
As the end of the year approaches quickly, some PM’s are going to be trying to creating roadmaps for upper management. It’s a fact of life, and sometimes it can’t be helped for whatever the circumstance. Ideally, you have a roadmap process you’ve been using throughout the year and nothing really changes for you.
I’ve got a pretty good method and format for creating these things now. After being bit in the ass one too many times, and really seeing how roadmaps can hurt organizations AND help them, I’ve found myself creating two types of roadmap: the internal and external. Before getting into the details of each of these, I’ll cover some general things.
I always prefer laying roadmaps out quarter by quarter. This is a broad view, and really defines that the roadmap is by no means a release plan. Release / iteration plans are derived from the content on the roadmap itself, so it can be more on the side of high-level.
The second major thing for me is, they change. Roadmaps are a critical part of the process, not the end result of some huge, year-long planning effort. They are liquid, and meant to be reviewed regularly. Obviously, if you have weekly management or product meetings, they aren’t coming out and getting changed that often…
Lastly is alignment. A great roadmap must be aligned from top-down. The business vision and objectives must be taken into account, along with all market data that has been gathered, and any new innovation steps the company feels is necessary to move the product and business forward by leaps and bounds.
The Internal
Essentially, this is for upper management, development, and maybe some members of the board, depending on their level of involvement and how comfortable the CEO is with providing this level of detail.
Creating this is relatively easy. Simply take a big block of the four quarters and put big squares in where the releases will (approximately) be. This will all be wrong, so just get it done. When you first start developing roadmaps, they really aren’t going to be right. They won’t probably be right even 6-8 months in, so you are much better off just getting the content down.
After you map out your release blocks throughout the year, check to ensure nothing looks wildly out of whack. Are you attempting to do 3 major releases in a single quarter, for example? Maybe 8 minor releases in a month? The reverse may also be true, depending on your situation - trying to do 1 minor release very other quarter, for example. These are all bad news, and indicate the roadmap should be re-evaluated.
After you have this down, for the internal version only, you’ll want to bullet out as many features (maybe all features) you have planned for each release blocked within the quarter columns. Remember, this isn’t a release plan or a requirements document so you can be more high-level. You really just want to offer a view of, “these are the features coming up.”
Remember, each feature you mark down will usually need more justification than, “I think it’s really neat!”
The External
On the external view of the roadmap, you want to stick to themes. No specific features really get mentioned within this stream - just prose-like descriptions of the releases you have mapped out. This affords you with the flexibility to send a roadmap out to Sales - it may even work work for board-level presentations.
The goal with this type of roadmap is to offer folks talking points and broad timelines about what the product will shape up to be throughout the year. It provides a great view, without going into detailed feature sets, about what “themes” you are looking to inject into the product(s).
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.
Shipping the v1.0
While the indigestion and heartburn hasn’t completely gone away yet, and probably won’t until we roll through our first update to the product, we have gone live (read: not fully launched with all the Marketing excitement behind the release) with a milestone product release for our company.
It feels damn good, but also a little daunting.
10 products in the portfolio, and the majority of them are going through mid-large type revisions, or are still in the v1.0 cycle.
I have my eye both on building out roadmaps, cross-product integration, listening / gathering market feedback, but also not getting too attached. We’re going to have to EOL something in the future, so treating a product like your new cute fuzzy little puppy may in fact not serve you too well.
Also, quick thanks to Scott and Roger for their support & feedback. Having contacts and friends in the same position as you to be able to call on for advice and guidance makes all the difference in the World.
I may in fact have time to blog some more….hopefully.
