Managing by Milestone
I wanted to let everyone (well…all 1 or 2 of you) in on a little secret a learned recently: there are two ways in which you can be accountable.
You can be accountable for work, or you can be accountable for communication. And yes, there is a pretty big difference.
Now, of course, in the fast-paced “hectic” start-up world where everyone has to be good enough to a) wear multiple hats and b) want to contribute and wear multiple hats and be excited, there are many (if not all) the folks in the company that are both accountable for some work, and some communication. However, I just wanted to post about this because what else are blogs for if not to ramble on until you get something in your own mind?
So, what to do with this revelation. Well, being a product-centric/happy guy, I float towards wanting to be accountable for communication on projects that are not directly product related. This means I favor a setup where you manage by milestone and not detail. Why is that? To me, it’s a boatload more effective to sit down for 30 minutes each week with a team lead, go over key milestones identified at the outset of the project and log the issues as opposed to sitting down for 1+ hours with everyone on the entire team and going through the plan point-by-point.
Why do I care what Suzy is doing on Tuesday of next week? If you do, you might be slipping into a trap of micro-management.
Now, of course, anything I say should be taken with a grain of salt. I know nothing from nothing and am simply a geeky pleeb trying to work all this out and how it can work the best in the scenario I’m currently in.
With that being said, development project management has to be done differently in a small environment in order to work. It HAS to be agile. I’m 100% - no, 1,000% - convinced of this. There is NO other way to go.
My first step? Tearing up any spreadsheet that I had related to tracking dev schedules. What goes in its place? I’m pulling out some flip charts and writing the following:
Product Name - Release Number / Date / Sundial Location / Whatever
- What’s in the backlog?
- What’s been planned?
- What’s in development?
- What’s ready to ship?
I then track the overall status of the release itself. Smiley face / sad face, thumbs up thumbs down, whatever. It needs to be clear, it needs to be somewhat interactive, and developers have to be able to walk over to this thing and scratch their names off, or move a sticky note with a requirement on it to the next grouping (for example, development to ship / qa, whatever) when it’s ready to go.
People love to check their own names / tasks off of lists. I love to see people checking their own names and tasks they have ownership of off lists.
So, let’s throw another kooky wrench into the mix? What if you want everyone to see this schedule so they know what is being worked on when it comes to the life blood of the company (i.e., the products themselves). Well, that’s easy if everyone is ass in seat, in the office. However, that’s not always the case.
I’m thinking a Web cam.
Will this invade privacy? That’s the initial concern. How can you avoid that? Get 1 camera, point it at the dev schedule that’s on a wall in a grid taped together or on flip chart paper taped to the wall.
Oh wow — didn’t I just recommend to violate a cardinal rule of product management? Never, ever give sales specific dates / info on the dev schedule! Blasphemy!
Ehhhh…I’m starting to think it’s not going to matter so much — especially now that I’m dealing in more of a consumer-based mindset. Which, I’m loving by the way (whole other blog post on that bad boy topic).
I doubt any of that made sense. Which is fine. It’s working for me, and in my head it all makes sense. The litmus test will be to see if it makes sense for everyone else that it needs to make sense for. And if I can keep it clear enough in my head that when I start to tape big pieces of flip chart paper to the wall behind my desk.
God, I love my job.
I Love Clicking
I love it when things just “click” in my head and I just “get” them. I’ve found that this is how I’ve learned / progressed the most. All of a sudden, after breathing / eating / living a single thing for long enough, all of the factors that I’ve been questioning just come together and get really clear.
There is plenty for me to learn, and much of it will come through talking to those that may have already lived through similar experiences, as well as trial-and-error. I’m good with that, because I feel like I can learn from, and recover quickly, when in error.
On the other hand, I also feel that even though I don’t have a bajillion years of experience, my instinct guides me a lot and it is awesome when these “clicks” do happen. It doesn’t happen frequently, and to be honest, I’m glad it doesn’t. But when it does, I initially find myself thinking, “this can’t be right–oh, wait — yes it is!” Coolness.
Ok, crazy rant done with.
Why XPM Is Key
What the hell is XPM? extreme Product Management. Cheesy buzz term? Oooh, yeah. Important? Yes. Why? Let’s discuss.
I’m not a big company guy, which I think I’ve established over the course of several blog posts. Small companies are typically tight on many things — some which are:
- Time
- Money
- Resources
So, what are they NOT tight on?
- Wanting success
- Feature & innovation ideas
- Product ideas
- The need for speed
So far, cool, right? Well, not really. Hows does this pan out in the end? Folks can get real ansy in a small org when things take too long. Small companies can move faster than IBM or GE, right? Yes. But remember, moving fast is only one piece — stopping / turning on a dime is something else.
Waterfall projects are a pain in the ass, IMHO. Why? Well, because typically, at least in my universe, no one can tell the future. Now, I could be on my own here, but I’ve never been able to predict (with some semblence of accuracy) what is going to happen 6-8 months from now. So, where does this leave PM’s? With a need to be extreme. But, I hate that term — I prefer agile.
Traditionally, you give developers requirements 1 time, they implement, and that’s it. If the requirements are wrong, then the PM gets slapped around / chained up / whipped / etc… Why is it that someone who is essentially tasked with telling the future gets in trouble when they are wrong? It’s a simple fact — requirements will never be right in all cases. Using an agile PM concept can solve this by allowing a PM to put requirements in front of a developer, and iterate on them (within reason / bounds) to ensure that the end result will pass BAT, and it’s what was envisioned.
Of course, I’m a silly kid without any grey hair, so don’t trust me — you can trust Steve Johnson. You can trust Roger Cauvin. You can trust all those PM’s with 15-20 years experience that I listen and adhere to and learn from daily, to make sure I can at least voice on this blog what I feel is a successful way to do things.
Why limit the success of a product by being able to tell the future? I do agree, that with something that’s agile, boundaries have to be established. Otherwise, you run the risk of never actually shipping anything due to perfectionists. However, factoring in the need to iterate on the foundation of what is actually being developed, at least from where I’m standing, is a great way to ensure things are more successful than trying to drive everyone into a dense white fog without being tethered together at the wrists. Reset, re-adjust, re-balance, whatever — set the milestones, work towards them, and have everyone on board with the idea that: yes, requirements are going to change to make sure what we ship is killer.
Now, I have used the term “concept” in this post more than once. I also believe that shoving “agile methodologies” down everyone’s throat is not the way to go. However, making sure that market knowledge / requirements are not just pipe dreams (and they all to often are), is critical. Don’t just say you listen to customers — actually listen to customers and do your homework.
And for me, it all ties into not relying on someone being good / accurate at pulling out their crytsal ball. Don’t set dates for things to be delivered if the requirements aren’t understood, and developers don’t agree. After all, they need to know what it is they are committing to before committing to it. Saying everyone is going to go really fast and then leaving it to chance and “good solid hard work and long hours”, is not common sense. I’m not advocating process-heavy, goliath type stuff. I’m advocating concepts & understandings within an organization that can be used during execution to help ship cool / great products.
I’m advocating agility.
Delivering Clarity
I’ve never worked with non-software products. This could be perceived as either a curse or a blessing, I suppose. I don’t know what a Product Manager for a non-software product would go through to ensure everyone in his or her company “got it”. However, one thing I do know, it’s tough to drive clarity in software companies.
It’s invetiable that people just won’t get it. It’s not their fault, by any stretch of the imagination. But, as a PM, I see it as a responsibility to get everyone on the same page. Having just stepped-in to a company that has multiple lines with multiple technology-based products, this has been an overwhelming task.
There are plenty of things I thought would work at the outset, but I’m molding to shape what’s best for the company as I go. Since all of the products I’m working with combine into a “ecosystem” of sorts, it makes it tough - the natural thing to do is try to cover everything at once — all for one and one for all sorta deal. This doesn’t work — at least, not in the scenario I’m dealing with.
The approach I’ve decided to take is, break these out, simplify where possible, and make sure everyone gets it. I’ve been working this strategy for around 2 months, and it’s going well. There’s some places where I can’t enforce this and need the help of my boss and others, but that’s OK. The thinking I’m trying to change has been going on for over a year. I’ve never thought it’s impossible to clear things up — maybe difficult, but if it wasn’t it wouldn’t be a challenge.
So, what’s my overarching theme? Keep it simple stupid (K.I.S.S.). Simply the lines / suites, and productize each product as a product - not as an “ecosystem”. Not everyone can keep a picture of an entire system in their heads, but they can understand “this is product A, and it has features B and benefits C — here is a 50,000 foot workflow”. Then you can start getting into how each product works together.
One thing I’m picking up on does relate back to people having a set image in their head of things for over a year. I’m noticing that, even though it’s easy to see how easy the products are once you get it and it’s explained in the right way(s), there’s slippage back into the old ways of thinking.
I guess that’s natural. It just takes time and consistency of message. Making sure your productizing to the right standards and then take that message and push, it should be fine. Yes, I’m dealing with this for the first time, and learning some GREAT lessons along the way. But I don’t know if it would change from one company to the next. You learn to recognize when you’ve tried to deliver clarity in one way and people react another, but outside of that, it’s sorta just trying to find the right way to talk about products to the specific company.
Maybe I’m relying too much on the start aligning but that’s just what I’m seeing thus far. Hopefully I don’t sound too much like a crazy-person.
Company-Wide Philosophy
Each day I work at a small start-up, I really have a stronger notion towards making sure everyone can put on their product management “hats” in different, and unique, situations.
Because the entire organization is driving towards getting products / services to market, and everyone wants them to be as successful as possible, it’s important that certain product management activities get shared with different people in the company.
For example, say you are working with 5-10 clients in parallel and a client comes forward with an enhancement request. Would you arrange a call with your product analyst? Probably not. You want to be in a scenario where your account team knows how to gather requirements the way your development team likes to get them. Beyond that, they should also be knowledgeable about the process of taking those requirements through to release.
Requirements gathering may be a broad example but the concept can also apply to positioning, documentation, and in essence, driving products forward, which should be a major goal for everyone. The whole business should want to make sure what is being sold continues to move ahead, be innovative, and easy to communicate.
