Quick / Quick & Good
Let me start this post off with the clear thought I’m going to attempt to discuss below. I say attempt because, god knows, I can very easily get lost in the writing and it easily becomes stream of consciousness. So, if you nod off while reading my blog, don’t feel bad. Because, I might be nodding off while writing it. But, I digress.
OK, the thought.
There is a MAJOR difference between doing something QUICKLY, and doing something quickly that’s of HIGH-QUALITY.
As you’re reading this post, remember the fundamental project management equation, which applies to product / project / program managers alike regardless of if you are working within an eXtreme or waterfall methodology.
scope + cost + schedule = quality
There’s been a lot of focus put on “speed” and “iterations” with the whole web two dot d’oh! craze going on these days, and I wanted to touch a little bit on that.
I don’t mean to rain on everyone’s “just get it up & out there parade,” but there’s still a need for attention to detail and quality. It seems to me that no one pointed out to the agile pushers (me being one of those folks) that while doing things iteratively and quickly is nice, it requires experience.
I’m going to go back to the age-old analogy of building a house. If you were having a house built and hired contractors to do things, not necessarily iteratively (because I don’t know how you could put up a house and then continuously improve it), but quickly and of high-quality, would you want kids that were just out of carpentry school doing it? No freakin’ way.
That doesn’t mean you need dinosaurs up there laying shingles on your roof, because they would arguably cause just as many problems as the people without any experience, but you still need that knowledge of having done this before to get it done properly.
I can’t talk too much, because I myself don’t have 15 or 20 years under my belt, but I have been in software (Web applications specifically) development for close to 7 years, so I do know some things about creating applications and working with customers / users to improve them.
Don’t expect to hire cheap labor, who hasn’t done the work you want to do and expect to move at lightening-speed AND get something up there that will propel you to the level of greatness. It just doesn’t happen that way. Again, one of the major elements to be successful at agile development is you actually need developers that know what they are doing to get things done in that fashion.
…and developers that get one iteration shipped and are chomping at the bit to tweak existing things and continuously improve what they produced so it’s the best it can be, while at the same time making the product more exciting by adding enhancements coming in from the market.
Another component that may get lost in this “agile” development way of thinking is actual accountability. It’s easy to lose the team and control, especially when the experience isn’t there, in the midst of, “we’re just going to get this done and up and then refine.” Quality needs to be minded, and those involved have to be held accountable for what they own. It’s still a project, folks. Don’t lose sight of that. Just because you’re not creating 1,000 page requirements documents and maybe you are writing your project plan on note cards doesn’t mean these fundamentals get thrown out the door.
Planning & Reports
I like planning - OK, maybe a little bit too much. There’s just something about having a plan, having it structured nicely, and keeping it up-to-date that’s exciting for me. I thought I would share some of the tricks that I’ve picked up on over the years from both having doing it myself, and from having talked to others (especially project managers) about how they approach different scenarios.
First, I think sharing one of the most important lessons I’ve ever learned is pertinent. There is a very big different between being accountable for communication and being accountable for the work. This ties directly into my planning / project mgmt / reporting philosophies.
If you are accountable for work, you are right in there - down & dirty, doing tasks that are associated with a project day in and day out. If you are accountable for communication, you are typically meeting with project managers / team leads regularly to discuss the issues they are having managing to their milestones. But again, this ties directly into some of the things I want to write about in this post.
1. Find Out Your Milestones & Manage To Them
There’s nothing peskier to me, and seemingly something that can easily facilitate micro-management, than NOT doing this. If you don’t know any milestones on a project you are either a) working on or B) responsible for managing and communicating, figure them out as soon as you possibly can.
I would put money on the fact that if you are working with a team to execute a project and it doesn’t have milestones, there is confusion. People are probably doing makework, overlapping work, not sure what else needs to be done (which hinders top performers that like to be proactive) - all of these things directly contribute to project failure.
If you don’t know how to create a milestone, there is a pretty good description on Wikipedia. Check it out.
Make sure once you identify them, everyone on a project, or everyone that’s in your team knows what they are. Then, in your weekly reports up the management food chain, or to your entire team, you can discuss project status to the MILESTONES, not to what Jenny ate for breakfast on the morning of the 21st.
Again, if you are accountable for communication, meet with team leads each week (or day depending on urgency) and then report on their progress in achieving the milestone. It’s the team leads job to manage the detail contributing to the success of a milestone - not the “project director” or “managers.”
2. Create a Simple Plan
If you are accountable for the work, identify everything that needs to be done - and thus, create the “project plan.” You really should be feeling out how complex this needs to be. Typically a fully developer MSFT project plan isn’t required, and while I have tried them, I like to stay away from them when I can. I will typically prefer to use Excel. Yes, some knowledge of how Excel works is important - but that shouldn’t be too hard to obtain. You don’t need complex formulas to create a project plan.
I will typically include columns like Task Summary, Owner, Status (%), Due Date, and Notes. Unless you are getting into hardcore time management, variance tracking, noting things like estimated start dates, actual start dates, cost per task, etc… aren’t probably just overhead. I will sometimes include estimated and actual end dates. This helps during a post-project review to spot any problems that might be cropping up in certain people’s estimating.
The key here is to keep the plan updated. It’s easy to create on, and let it grow out of date. I like to print a copy out at the beginning of the week and mark it up throughout the week and make the updates on a Friday before / during writing a project report.
Remember: simple is key. Oh, and making sure people can actually read them when you print them out. I like really small type - others don’t =)
3. Scorecard
For me, I love using project scorecards. If you have a really large project you are managing, one per project might be required - for many smaller ones, you can get away with having one project scorecard for them all.
In the scorecard, I indicate which projects are green, yellow, and red. I have space to note any issues that have come up and need to be solved after speaking with team leads, or in my own projects. If you are doing resource loading, high-level cost estimates can be indicated here as well. Also, if you are doing EV tracking, you can note differences between estimates to actuals and overall totals.
This scorecard will get attached a regularly weekly report. It helps to show the big whigs where troubles lie, what issues currently exist, and how those issues are being solved. And, what does mgmt care about the most? *cough* the money *cough*. Yes, it does include that as well, as I mentioned.
These aren’t hard & fast rules - just things that I’ve found to work for me as I’ve progress through trying certain things out. Project management is such a key part to being a successful product manager, that by knowing what works for you and in your own scenario, it can help contribute to additional success.
Excelsior!
My Customer Support Story
I have to admit that I’ve kinda felt left out of the whole customer support story loop. Everyone seems to have their “yay company x!” story for when they were able to get quick response times when they needed them and actually talk to people on the other end to ask what’s up.
Well, no more. Mine happened today.
I needed to sign a piece of code prior to it being released, so I got my hands on a VeriSign Code Signing certificate. I was (and still am) planning to sign using Microsoft Authenticode.
So, I mosey over to the VeriSign website, which includes instructions for doing this. The first step is to download the Microsoft Platform SDK — 1gb of stuff. 999.99mb I won’t need, but whatever.
I start through the steps — 1, 2, 3 OK, no problems. I get further down the list — uh-oh, something ain’t right. An instruction doesn’t match to the software I’m using. No problem, I send an e-mail to VeriSign asking for help.
No go. I get the, “it’s Microsoft’s toolset, not our problem” response — no once, but twice. grrrr…
So, I check out VeriSign.com, and get to their Executive Management page. I find the right person, guess her e-mail address and send off my query. No bounce, so I figure it got through — I didn’t expect to get a response, mind you.
I was proven wrong. Within 1/2 hour, the Executive VP of Security Services, a lovely woman by the name of Judy Lin, e-mailed me back, apologizing and cc’ing her head of support. The head of support then forwarded my mail on to one of her team leads, who called, left me a great VM, and I will be getting in touch with him to work through my problem later today.
AWESOME!
I’m sure this type of thing happens more than once a day. Some content is neglected on a large, sprawling website, a product mgr forgets to get copy changed to support new versions of tools that things rely on to work, etc, etc… It doesn’t seem like a big deal, but it is.
The more this occurs, the more strain that goes on support folks, boosting costs. If the software / instruction / links / etc… were up-to-date, I wouldn’t have taken up a total of 5 people’s time within Verisign. I’m not dogging VeriSign at all, because they totally came through, and I hope that my experience leads them to supporting “Microsoft Platform SDK for Windows Server 2003 R2″ in the future. It’s more of a general thought.
This all contributes to the product. A product is not just “upload a ZIP file and go.” It’s packaging, documentation, logistics internally, support, and making it easy to do business with your company.
Creation is only 1 component of making something successful. Arguably, it’s the maintenance of items that bite you in the ass. They have an easier time slipping off schedules to make room for new, shiny, bright, fresh, innovative features.
Don’t neglect the bugs and step-by-step updates. It’s all important to release a successful product.
That’s the Way to Go
Get a codin’. We’ve found something that’s working really well - a way for teams to work together and get things accomplished quickly and effectively.
This does not involve the use of 593 page requirements documents or extremely detailed & complex workflows. Nope. What’s needed is a few simple things:
- Vision
- Code
- Wireframes
- To-do list
…oh - and lots of iterations.
When you are trying to get a product up & running, I’ve found the natural thing to do for people is to lean more towards a “corporate” style approach. Trying to identify every detail is OK when it’s necessary. It does hinder the ability to move quickly.
…with the caveat to this being, “you must have intermediate -> senior developers that know what they are doing.”
Taking up time to do usability studies? Not required prior to launch - especially for a Web app. Usability studies, when done right, are OK - but they are so easily done wrong. Also, definitely not something that’s totally needed for a product being constantly iterated on. Watching the audience use it in their natural environment is beneficial, as is listening / gathering market feedback and cycling iterations.
As an aside, I prefer feedback to come in to me directly, which I folder in Outlook using rules. This includes anything from the market via either an e-mail address or form. I like to get as much as possible, and being prioritizing by way of a spreadsheet right away - the data is very intriguing to me.
Get coding. It’s OK if the code gets ahead of the wireframes. Get the functionality implemented and tested. The wireframes then serve the purpose of cleaning things up so developers don’t have to worry about how form elements will be aligned, or the copy to use for error messages and other things that geeky product managers like me are really into.
I’m now part of a team that’s got this type of structure working. Let me tell you - it friggin’ rocks. Agile, rocks!
Callin’ Da Users
Get your clients on the phone. Listen to your users.
I was just reminded of how important this is. Of course, while working in both the enterprise and consumer streams there are different approaches to this.
I’m not a huge fan of the idea of “user groups” or “usability studies.” Now, this doesn’t mean that I’m not all for heading on-site and watching people interact in their natural environment with a product.
On the “enterprise” side, this can be as easy as a quick e-mail to setup a time to chat. It should be brief — not anymore than 10-15 minutes. An hour long conversation just won’t fly.
I recently chatted with RallyDev after doing a trial of their products. I was contacted by their Director of Marketing, Anne Greenshaw - a wonderful person. Very nice and well spoken. She asked me some great questions, and I gave her as much info as possible. I hope that it helps them make their product a little better.
There are many different ways to gather market feedback. But, it’s critical. For web apps I prefer web forms / e-mail addresses a la Google, and just talking to users regularly through channels that are appropriate for the identified audience. For businesses, I recommend picking up the phone and calling.
My process consists of marking things down that I encounter (PM’s aren’t barriers, but proxies), and then indicating if they are categorized into buy, vision, competitive, or usage. Each time I see the same idea present itself I increment the score for it.
Once you have this data, it’s easy to justify your decisions and requests. If 150 people are asking for an enhancement and you have a user base of 1,500 people, that’s 10%. Chances are if the enhancement gets made, your users will be happy.
Product management is one of the funnest jobs ever.
