Looking for a Product Manager
Are you a product mgr, or know someone that is? I’m looking for a solid guy / gal to join my team. If you know anyone, or are a candidate yourself, drop me a line.
UPDATE: I’m happy report that we managed to secure a great product manager for the team, and we are all looking forward to him coming on board and getting started!
Behind Closed Doors
I just finished reading perhaps the most honest and streamlined book on management I’ve ever read. Behind Closed Doors: Secrets of Great Management is amazing.
It works through the story of a Director of Software starting his new position at a new company and all of the challenges he faces with while starting to work with his team.
Some great principles are covered, and the book provides examples and tools for communication and working through the day-to-day challenges that management presents.
While it’s focused on a high-tech, the fundamentals provided can be applied to any industry. While reading, I kept going back to what I’ve learned from Manager Tools for reference, and reflecting what the authors of the book were saying to what Mike and Mark discuss on their outstanding podcasts.
While a lot of the content was familiar ground, the book offers a little bit more of a relaxed feel to giving feedback and executing one-on-ones that I preferred. The Manager Tools is very, very good - but I’ve always found it to be a little bit more formal and targeted towards large-scale organizations; not start-ups, which is the world I’m from.
In any event, I encourage everyone to buy the book and subscribe to the Manager Tools podcasts. After (even 2 weeks) you’ll have a better foundation for management.
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.
Estimation
Steve Johnson posted a great article on prioritization. I firmly believe in many of his points and stances.
There’s one interesting point raised here dealing with estimation. Having 2-3 different groups of people determining what features go in and when they will be done simply serves to confuse. Especially when it comes to estimation - developers don’t always take in to account when everything else around a release or a feature will be done, simply because it’s not their job. Their job is to code, and estimate how long that code will take.
Sales and Marketing may like to hear that a feature is going to make it in to a release sooner rather than later, but that’s why those dates and estimates need to come from product mgmt and not development. The code is not the product - it’s the code plus everything else around it.
It would be nice if all documentation, testing, training, and other materials are always ready when the code is, but that hardly ever happens, especially when your team has a lot on the go. It should be baked in to the culture that product knows when things will be done, not development alone. Again, the answers might be “better,” but not necessarily correct. And nor should they have to be.
This is especially tricky when it comes to certain developers. When asked how long it will take to code 1 thing, one developer may say, “meh, couple of minutes” and another may say, “meh, couple of hours.” Again, these types of answers are off the cuff and should be treated as such. Especially when a customer is relying on the response to be correct.
It is extremely tough to estimate accurately. And, the best way to get better is to either a) hire people that can estimate really well or b) track actuals and then measure variance. The latter is tough when you don’t have formal time tracking systems in place.
The other alternative is to channel things through product, who should act as a centralization point on estimates, priorities, and keeping all components of a release timed and tracked. The answers may not always be favorable to Sales and other front-line facing functions, however, chances are, they are taking everything in to account as opposed to a single set of tasks / action items that must be executed prior to completion.
