Archives For February 2009

The Tool Does Matter

February 24, 2009 — Leave a comment

I tweet’d the following late last week:

I’m not arguing that culture matters more than the tool. But it’s naive to say that all tools are created equal. Tools do matter

I also posted the following comment (a response to another comment) on my blog:

I can’t argue with the culture point; any tool will be more effective if the culture is one that embraces the purpose for which the tool was procured. I attended a Forrester/Newsgator webinar last week in which they predicted microblogging applications to have negative to minimal impact on E2.0. I disagree with their prediction because I think Microblogging is one of the best tools for KM that I’ve seen. So, in this case I do believe tools matter. I see in our organization that many of our KM applications discourage usage because of their cumbersome interfaces and non-intuitive design. You mention that Twitter ‘is simply a type of communication tool.’ I think it would be better to say that Twitter is a simple communication tool. Makes a difference. Additionally, because such a high degree of knowledge is social, microblogging derives another advantage. In many ways I think Twitter is a better KM tool than most tools designed with KM as an end goal.

I hear it time and time again, but I don’t agree with it: Tools don’t matter.  To be fair, when you hear this phrase,  you need to also understand what’s not being said, but rather implied:  Culture matters more than tools, if you have a great tool w/o a culture to support it the tool will not get used.  I agree.  What that doesn’t mean, however, is that tools don’t matter.

Tools matter

This or this.

What?  C’mon, tools don’t matter.  Remember?

I’ve been pushing (with lots of success, kudos to my company) to bring in an Interaction Designer to help make the apps we develop better.  Part of my campaign included a bit of propoganda:

That presentation was the first time I really understood that design (the tool) matters.  There’s a reason people want the iPhone and not the Zack Morris phone, or the G1 for that matter (it’s the same reason that people prefer the G1 over the iPhone).  There’s a reason we’re not still on DOS.

Again, I’m not saying tools are more important than culture.  In fact, I’d say failure to change culture is one of the biggest reasons a tool fails.  I see it time and time again.  I’ll build an app for a customer to their specifications (I’ve got the requirement spec they signed off on) but when no one uses it they blame me.  Me!?  They tell me it wasn’t designed with the user in mind (rolling my eyes).  Uh huh.  The one thing my customer forgot was a change management plan and a marketing campaign.  It’s strange how whenever an app fails, a CM plan is missing…and then it’s the development team’s fault.

As you can see, I do believe in the value and necessity of culture change.  But I also believe that even if a culture is willing to (insert desired behavior here) they’ve got to have the right tool to do it on.  People get excited about tools, they like showing them off, they love the moment of realization that someone was thinking of them when designing the tool (‘it knows when I’m using it as a phone and holding it up against my face!).

Tools matter.


If you’ve managed a project before you’ve probably been burned by requirements at some point or another.  On one project you’ll spend way too much time trying to define the requirements down to such a detailed level you have no money left to do the development.  Customer gets pissed b/c they don’t get their product.  On another project you’ll agree to some high-level goals and do the development.  You deliver to the customer and they tell you it’s not what they wanted.  Frustrating.  

So, as a PM you know you don’t want to be at either ends of this Requirements spectrum, but you need to turn out a product that meets your customer’s needs.  What’s the middle ground?

The approach I’m taking on my current project is as follows:

  1. Spend good time (8 – 10 hours) hammering out as many requirements, with the customer in the room, as we can.  We are using the customer’s goals as the starting point.
  2. Once we have a solid concept of what the customer wants, we are going to start prototyping.  Any requirements that didn’t get finalized in Step 1’s 8 – 10 hours of meetings probably didn’t get finalized for a reason…the customer doesn’t know what they want.  And it’s not their fault, I’m not placing blame.  As a PM you have to understand that this is going to happen, cut your losses and move on.  
  3. Once we beging prototyping iterations we’re going to meet with our customer on a weekly basis.  This does a couple of things:  gets the customer’s buy-in, allows them to provide input and further tweak their ‘unknown’ requirements, and it prevents development from getting too far down a potentially unwanted path.

The more visionary the project (enterprise social media PMs take note) the less you can talk about requirements up-front and the more ‘show’ you have to do in the prototype phase.  You’re dealing with people who have goals, but don’t know how to get there.  They get the warm fuzzies when they can see something and play around with it;  they know what you’re talking about and can provide feedback.  Then maybe you write the the requirement and get them to sign off on it.  (But, only after they like it 😉 )