Category Archives: Project Management

Who cares about the soft stuff?

The longer I live, the more I internalize it: We succeed or fail to a large extent because of our ability to establish and sustain good relationships. Yes, you need a strategy and need to be smart enough, but PMs need to be leaders. If no one is following you, you’re not a leader!

Think about your own career ups and downs. How many of failures are you blaming on others? And how many successes do you chalk up to your own brilliance? I suggest that you take a look inward and you’ll find the seeds of many of the problems you experience in the outside world.

My friend and colleague Michael Papanek has just launched a new blog covering topics that will help you in your career as a product manager. Michael specializes in strategies, skills and tools to implement change. Michael has taught me a ton about collaboration, leadership, and personal and organizational change. If you’d like a sample of his thinking, here are some articles to get you started:

Hearing the hardest feedback

Five steps to giving feedback

Driving success? Try fewer controls

Removing stop signs in your organization

Finally, I interviewed Michael a few weeks ago on what he calls the “Resilient Relationship”. You can hear our discussion here.

Every PM should be thinking about leadership and organizational issues!

– Alan

Advertisements

What Origami can teach us about Product Requirements

Tom Grant has started an interesting series of posts entitled Against a Grand Theory of Product Management. The articles are interesting reading, but make sure you have your thinking cap on when you start, because Tom is discussing an important but rather abstract topic.

He pulls in references ranging from Middle Range Theory (something I’d never heard of before) to Darwin’s theories (something I think we’ve all heard of but probably don’t adequately understand) to help convey his points. I had to read the posts a couple of times each to better grasp the specifics of his arguments.

In Part 2 of his series, Tom asks:

If someone can figure out why even the most meticulously written and reviewed requirements don’t stop some tech companies from making products that their users don’t like or can’t understand, that’s a big contribution to our little field of study. Best to have more middle-range theory before even thinking about the GToE [Grand Theory of Everything].

This is a great question. But before I answer it, I want you to watch the following video. It is from a TED Conference talk given in February 2008 by Robert Lang. Not only is this a fascinating video, but as you’re watching it, keep Tom’s question in mind. Don’t read on though until you watch the video. 🙂

[BTW, if you are impatient and read ahead, the important stuff starts at about 2:30 in the video.]

Lang talks about the evolution of origami, that took it from a traditional Japanese art form that most of us associate with creating things like this:

and turned it into an art (and science)  form that allows people to create things like this:

And what caused that evolution? In Lang’s words, the answer is “mathematics”, or more specifically, the creation and utilization of a set of rules that provide a language for defining what can and can’t be done in origami.

The rules define the crease patterns — the lines along which folds are made — in the paper. And there are 4 rules:

  • 2-colorability — any valid crease pattern can always be coloured with only 2 colours and will not have the same colour in two adjacent areas.
  • modulus (M-V) = +2 or -2 — at any interior vertex, the number of mountain folds and the number of valley folds will always differ by 2
  • For any vertex, the sum of alternate angles around that vertex will always be 180 degrees. e.g. a1+a3+a5 … = 180 degrees  & a2+a4+a6… = 180 degrees.
  • No self-intersection at overlaps – a sheet when folded cannot penetrate itself

[Note: if you don’t understand these rules, watch the video. 🙂 ]

Now these 4 rules define the properties of valid crease patterns, but there’s still something missing. How can those rules be applied to create sophisticated origami? In short, what goes in the box? (see 4:40 of the video)

Lang discusses that as well, and provides this diagram:

In short, the physical subject is reduced to a tree figure defining the key components (“flaps” in Lang’s terminology) of the subject. In this case, those are the legs, antennae, horns etc. of the beetle. That’s fairly easy.

Then some process must be used to take that tree-figure and create a base form for the final origami. He calls that the hard step.

And finally the base form can be refined to create the finished model. That’s fairly straight forward.

The “hard step” is accomplished using the rules defined above and the language for applying those rules. Given those rules are mathematical in nature, they can be written precisely and unambiguously and then executed to create the final model.

What does this have to do with product requirements and Tom’s question?

When looking at product requirements, there are analogies to Subject-Tree-Base-Model example given above.

  • Product Managers investigate  real world problems, needs, scenarios etc. (Subject).
  • They then take their learnings and create abstracted representations of them (requirements) using artifacts such as problem statements, personas, use cases and user stories (Tree)
  • These artifacts are then used by engineering teams to create prototypes and mockups etc. to ensure that the requirements were understood and addressed in the product. (Base)
  • The final product is built, tested, tweeked etc. with the appropriate “fit and finish” before being released. (Model).

Sounds pretty good so far right?

But herein lie the problems.

  • There currently is no language for requirements like the one defined for origami, that can precisely and unambiguously convey what is needed and define that in a way that ensures it can be built.
  • Requirements should be implementation neutral, but as we all know in technology, the ability to fulfill a requirement can often be limited by technology choices and decisions that were made well before the requirement existed.
  • Other constraints such as time, resources, knowledge, legalities, finances etc. all factor into how well a requirement can be met, or perhaps if it can be met or not.
  • In many cases requirements contain unknowns or ambiguities that are filled in by assumptions during the development process. This is a reality of developing products in a business environment.  In the origami situation, this is would never happen. A model (like the stag beetle) can only be built when the full crease pattern is defined.
  • There is no concept of people “liking” or “understanding” the origami in Robert Lang’s rules. i.e. Tom Grant asks about why companies build product their customers don’t like or understand.

This last point is key and deserves a little more discussion. What people like and understand is complex and is not static. In general, what people like is based on overall experience and emotion. It is not something that (currently) can be defined in a set of requirements.

i.e. users of this product must feel giddy with excitement the first time they use this software

So, can origami teach us something about product requirements?

Absolutely. The origami path from Subject->Tree->Base->Model forms series of transformations that is akin to the requirements gathering, communication and development process used when creating products.

Once a set of clear foundational rules for origami were defined and understood, not only did they open up new possibilities for forms never thought possible, but those rules formed the grammar for a language that makes precise and unambiguous communication also possible.

There is almost certainly a set of rules and language for precise definition and communication of requirements, but it has not yet been clearly formalized. That is likely a necessary stepping stone in the maturity cycle of product development.

But even with that requirements language, changing market landscapes, customer preferences and needs, technological, resource and time constraints will all work together to make product success a “grey box”, where those with great vision, insight and execution are likely to succeed but never guaranteed that success.

Saeed

Add to FacebookAdd to DiggAdd to Del.icio.usAdd to StumbleuponAdd to RedditAdd to BlinklistAdd to TwitterAdd to TechnoratiAdd to FurlAdd to Newsvine

Vote For Us! ComputerWeekly IT Blog Awards

It must be that time of year. We have been nominated (for the second year running) for the ComputerWeekly IT Blog awards. And just like last year, you can vote for us in 3 easy steps.

1. Click the “VOTE FOR ME” image on the right (or click here).
2. Scroll down to the IT Project Management category (#7) and select our blog ( On Product Management ) from the list.

3. Scroll down a bit further and press Done.

That’s it.

One more thing. Don’t let the fact that this is a ProJECT Management category fool you. There are other ProDUCT management blogs listed, and one of the criteria is that nominated blogs have covered Project Management topics such as Agile. And we’ve definitely covered that topic on this blog.

Thanks

ProductCamp Toronto – Oct 4, 2009

In just about 3 weeks, we’ll be hosting the 2nd ProductCamp in Toronto. Last year, at the first event, over 100 people came out to participate in a day of very engaging discussions and talks about topics on product development, product management, marketing, innovation and more. Some of the presentations and notes can be found here.

Pre-register today!

There are already about 150 pre-registrations for the this year’s event!

If  you want to attend, click here to add your name to the list.

It’s free to attend, and lunch is included(!),  so come out and spend a day of engaging thought and discussion with others like you.

Suggest a Session (or Vote for your Favourites)

In the spirit of BarCamp, the day’s sessions will be voted on at the start of the ProductCamp on Oct 4. But if you want to suggest a session, or want to present one yourself, you can do so in advance.

Click here to see the sessions and vote on them, or to suggest new ones of your own.

Become a Sponsor!

A number of companies have already agreed to sponsor the event, including:

  • The Ted Rogers School of Management (providing the venue)
  • Pragmatic Marketing
  • SevenL Networks
  • Greenscroll
  • MI6 Agency

Also, our own Alan Armstrong and his jazz band will play live at the end of day reception.

Thank you to all of these organizations. But we’re looking for more sponsors. Sponsorships are used to pay for lunch and t-shirts for all the participants, as well as materials, signage and other expenses that are incurred.

Your organization’s name and logo will be prominently displayed on the ProductCamp website, on the day’s materials, on the t-shirts, and significant mention will be made of the sponsor’s during the day.

If you’d like to become a sponsor and gain visibility with innovators in the Toronto area, contact us:

  • productcamptoronto at gmail dot com

Volunteer

We’re looking for volunteers to help with some of the logistics during the day. If you’re interested in volunteering,  you can indicate that when you register and someone will contact you.

Twitter – #pct2

Finally, look for the #pct2 hash tag on Twitter. We’ll post announcements via Twitter ahead of the Camp and hope to have some live updates on Oct 4.

Looking forward to seeing you there.

Upcoming ProductCamps

Add to FacebookAdd to DiggAdd to Del.icio.usAdd to StumbleuponAdd to RedditAdd to BlinklistAdd to TwitterAdd to TechnoratiAdd to FurlAdd to Newsvine

ProductCamp New York was last weekend and it appears to have been quite successful. Alan attended and wrote up this post about it.

If you missed the New York session and want another chance to attend one, there are 4 5 more in the works in the coming months, starting with ProductCamp Austin in only a few weeks.

ProductCamp Austin
Date: Saturday August 15, 2009
Location: The University of Texas at Austin, McCombs School of Business, Austin
More details: click here.

Followed by one in September.

ProductCamp RTP2
Date: Saturday September 26, 2009
Location: Cambria Suites, Raleigh-Durham Airport
More details. click here.

And 2 ProductCamps in October.

ProductCamp Toronto 2009
Date: Sunday October 4, 2009
Location: Ted Rogers School of Business @ Ryerson University
More details: click here.

ProductCamp Seattle
Date: Saturday October 10, 2009
Location: Amdocs, 2211 Elliott Ave, Seattle WA
More details: click here.

And to round the year off, Boston is holding their camp in November.

ProductCamp Boston
Date: November 7, 2009
Location: Microsoft New England R&D Center, Boston MA
More details: click here.

For information on these events as well as other events relevant to the Product Management, Product Marketing and Product Development communities, check out our Events page. And if you know of an event we should list, let us know in the comments of that page.

Saeed

The problem with “find an unsolved problem…”

The common wisdom for developing new products, goes something like this:

  1. Find an unsolved problem or an unmet need
  2. Identify who values that need
  3. Build a profitable solution for that audience
  4. Communicate the existence and value of the solution to the market
  5. Iterate as needed
  6. Reap the rewards

There are many variations of this list, but generally this is the conventional wisdom.

A while back, I wrote a post entitled. Forget research, let’s just build something! I started it with the following haiku:

Research a concept?
How accurate will it be?
Build something, then see.

In mature or maturing markets, its a lot easier to identify adjacent problems for a set of target customers and work to address them. There are many reasons for this, but a lot of it has to do with working within a specific context or frame of reference and evolving from there. The user isn’t forced to make a context switch to a completely new problem space or new set of actions, which may be a big leap for them.

But when trying to create a new solution or a new market, identifying “unsolved problems” that people will identify with becomes very difficult.

Example 1: Cell phones

For example,  consider how people first viewed cell phones. A lot of people couldn’t understand why someone would want to carry a phone around with them everywhere they went. I had a coworker back in the 1980s who had one of those big, bulky (even by standards back then) phones with a separate 5lb battery pack. The phones cost thousands of dollars, had poor coverage, and were very expensive to use.  What “unsolved” problem was being addressed there? In those early days, how many people would say “Yes, I have a problem big enough that I need to carry that device around.”?

But once the public became comfortable with cell phones, and the devices got smaller and more affordable,  additional features such as cameras and keyboards were added and usage spread very quickly. Now, 60% of people in the world have cell phones and there’s still a lot of room for growth.

Example 2: Rubik’s Cube

Now think about the Rubik’s Cube. This is the most popular toy in history. Over 300,000,000 units have been sold since it’s introduction almost 25 years ago. Could anyone have predicted it would be so popular? If you described the idea of the Rubik’s Cube to someone:

Imagine a 3x3x3 cube with each face having a unique colour and each face having nine independent squares on it. Now imagine if you could rotate the top, bottom, sides etc. of that cube around the central x-y-z axes so that the colours on each face are mixed up. Now the object is to take that mixed up cube and return it to the original state as fast as possible. Wouldn’t that be really fun?

What kind of response do you think you would have gotten? First, what is the problem that this toy addresses? Boredom? Curiosity? There is no problem really. The cube is a diversion for people. Second, it was originally built as a model by Erno Rubik, it’s inventor and a math professor, to use in his classes to demonstrate certain mathematical principles. The Rubik’s Cube is still on sale today and many derivatives of it have also done well in the market.

Example 3: Twitter

Finally, let’s look at the Twitter. .you can find stories of the origin of Twitter in different places on the Web. Here’s one from Wired magazine that describes it quite succinctly. The key line from the article is:

“I had an idea to make a more ‘live’ LiveJournal. Real-time, up-to-date, from the road. Akin to updating your AIM status from wherever you are, and sharing it.”

Now, I don’t know about you, but I don’t see any hint of solving any kind of problem there, or in the rest of the article. “Akin to updating your AIM status from wherever you are and sharing it”??? That’s what started it?

It sounds like the writer just thought it was a cool thing to try and do. Granted, Twitter still doesn’t have a sustainable business or revenue model, but that hasn’t stopped them from becoming a very popular service.

And so what?

So here’s the rub. Yes, these are only three examples, but I could have cited many other consumer, leisure or technical successes that had similar non-problem solving starts. The principle of finding an unsolved problem or an unmet need and then addressing it is a good rule to follow, but it, in no way, is the only reason to create a new product or service.

In fact for some successful products, it’s very difficult, if not impossible, to precisely state the problem that is being solved (e.g.  Heely’s roller shoes)

Or, perhaps there is an initial problem that is addressed, but the success comes from addressing another need or problem (e.g. Google started as a search engine, but found incredible success as an advertising platform).

A lot of successful products or services only became that way AFTER they were introduced to the market and people actually experienced them for themselves. In those cases, no amount of requirements gathering, interviews, focus groups etc. could have provided confirmation that success was in the future.

It’s important to remember when brainstorming or thinking of new products or services, to not simply fall into the trap of “conventional thinking”. If you have an idea, think it through as much as you can, but in the end, if you really believe in the idea, go for it. You never know where it high it will go and perhaps take you along with it.

Saeed

Competitive intelligence using lost deals

Another idea for PMs who lack permission to do win/loss analysis

Many PMs and PMMs complain that they lack the authority to perform Win/Loss analysis. And yet Win/Loss is one of the most powerful tools in the PM’s belt. In an earlier post I suggested a few covert tactics, mostly by starting small, finding low-stakes accounts, and begging forgiveness after the fact if trouble arises.

Here’s another idea for those who suffer this same problem: Gather competitive intelligence from last year’s losses.

You’re dead to me

deadpossumSales people rarely follow up once they feel an account is dead. Therefore you are looking to find accounts that sales considers dead, but in which you can get a lot of valuable information. My suggestion is to look through last year’s losses and identify large lost deals for which no follow-up has been done for 6 or 12 months. These accounts are dead; if no activities are scheduled, you can bet that sales will never touch them again.

Sales can legitimately protect their accounts if they are sensitive for some reason or have potential for revenue this quarter. In reality they may be protective because they fear what you will find. However it’s hard for them to argue that point; it would be hard for them to prevent you from calling dead accounts.

Call these accounts! If you are very fearful or have been given explicit orders not to contact accounts, you may want to ask permission. On the other hand, these accounts are so old and dead that you’ll probably get away with calling them. Call 5 or 10, summarize the results, and you might improve results.

What can be learned from dead accounts?

There are two main kinds of dead accounts, and you can learn different things depending on what you find

  1. Accounts that never bought: Why didn’t they buy? Did they really exhibit the problem that you solve? Is the problem big enough? Can you see a pattern here that would allow you to find market segments that just don’t care about the problem you solve? If so, this is valuable information! Other times, a lot of education or consulting is needed to get a customer project off the ground. Are there SIs or VARs who specialize in those projects? Perhaps these could become a channel.
  2. Accounts that bought a competitive product: I love these. Frequently your competitors don’t live up to the promises they made during the sale. The product doesn’t do what they promised, or it is so hard to implement, or so buggy, that the customer is frustrated. You probably won’t convert this customer (though you might), but you can learn a ton of information in these accounts about the shortcomings of your competitors’ products.

Just how dead are you?

Most PMs know that they should start every loss interview with an explicit statement that you are not trying to revive the account, simply learn from the past to improve the future. However, you will invariably turn up accounts where a sales opportunity re-emerges. This can happen when sales has simply not followed up, thought an account was dead, but the customer finally hit a wall and needs a product. Or it can happen when competitors’ products fail disasterously.

If you get one or more of these, treat them like gems. They are gifts to the sales team. Deliver them to sales management, not the sales person, and once you have delivered a few, you might ask again about whether you can do win/loss analysis more officially.

Good luck. Let me know how it goes.

And by the way, if you think you don’t have time for this activity, I refer you to: “Product Managers: Do the Opposite!

– Alan