Let us learn from others mistakes but with caution

My context here is a blog post on Alfresco's blog roll that discusses Vignette's slow but sure decline - full post here.
I don't have domain expertise in the CMS/ECM market and in general i agree with a lot of what Uzi says in his post. He points out the Vignette is "losing the people that they should keep. And they’re keeping the people that they should lose" - which leads me to assume that has inside knowledge about what is going on at Vignette.

My bone of contention is with that following phrase (please read the full post for context before jumping here)

And that’s where the old businesses are falling over. Customers cannot trust in how their money is being spent. It isn’t simply that Vignette’s brand has lost its trust - it’s that the products actually do not work.

Why? Because managers don’t know how to develop good code.

Give them credit, though, for knowing how to keep their jobs.

Umm... really, that is the problem --- "managers don't know how to develop good code". Wow! that scares me.
So let us trace this a little.

a. the brand lost its trust ---> (why?)
b. the products do not actually work ----> (i can see how this can lead to 'a') (why?)
c. managers don't know how to develop good code ----> (let me ask you again -- FOR REAL?)

Products don't work for a lot of reasons - chief amongst them being being poor software, poor understanding of the market problems, poor quality of requirements being given to engineering, ignorance of how the market has changed since v1.0 of the product came out, etc. But rarely does "managers not developing good code" show up on that list.
I would agree that if the product direction is driven by a manager with no technical background or software development experience, that is not a recipe for success. But that is a far cry from "managers don't know how to develop good code".

I understand the point Uzi is trying to make and the distinction being drawn between open source philosophies and "big elephants" but i caution against blaming everything associated with "big elephants" by association.

Imho, one of the reasons I think Alfresco executed so well out of the gate and continues to build on that momentum is Kevin Cochrane - who did not necessarily code (he might have a coding background, i don't know) but did a stellar job of understanding market needs and helped R&D build against it. Kevin's title was product MANAGER :-) if I remember correctly.

Disclosure - I have no stake, interest or strong affiliation with Vignette or the CMS industry. This is more from my perspective as a product manager.

Product Management: Thought exercise

If you were to product manage this, what would you dream about?

Are you a product manager - do you have this trait?

Through a pretty winding (web) road I came upon this blog post. The title says it all - "Strong opinions, Weakly held". I think that is my personality by default. The strong may be replaced with passion in my case :-) Often times in the past I have encountered people who were annoyed with the fact that I changed my opinions. It took me a while to understand that this is not a common operating model for a lot of people.

I would hypothesize that this is a pretty key personality trait if you want to succeed as a product manager. If you do not have passion or strength behind your opinions then your endeavors will fail at the first speed bump you encounter. On the other hand if you do not have the humility and courage to hold on to them weakly, you will find yourself leading battles not because you are fighting for the right cause but instead you are fighting because you want to be right. A big difference :-).

p.s In a lot of instances, people were annoyed with me for the right reasons but i am getting better ;-)

Serving too many Gods

This is my second "inspired by Jeff Lash" post :-). Jeff recently blogged about -> "Deliver customer value, not product features" which I think should be gospel for a product manager. Incidentally making this simple statement ring true is the most rewarding as well as the most challenging part of product management.

In my personal experience, one of the challenges with living up to this goal is the desire to please too many masters. As a product manager, you are in the middle of a lot of information flow and will get G2/request/demand/threats/requirements/... from a lot of sources. Accept them with gratitude, treat them with respect, process them appropriately but remember that your allegiance and goal is to delight the customer while solving the customer's problem and not to put the other stakeholder's product needs ahead of the customer. Your company expects this of you.


I leave you with this hasty diagram :-)



Happy customer picture is the property of Dan Taylor and is being used here thanks to his Creative Commons license. Thanks Dan!

Product Management: Art + Science + Intuition.

Jeff Lash's recent post caught my attention :-) [Stop gathering requirements:link]. I guess the title is meant to be provocative and attention grabbing (it worked :) . I agree with most of what Jeff says - I would like to clarify it further.

I would amend the title to say "Do not stop with gathering requirements". Gathering requirements is just the first step, the science part. The subsequent steps are where the art and the intuition factor in. The job of the product manager is to collaborate with the other teams (engineering, services, support, docs, etc.) and try to flush out the true customer market need that is buried within those requirements. Sometimes it means extrapolating (customer is not seeing their own problem), and other times it means pruning (customer is treating multiple symptoms instead of one cause).

To me it translates to the following guidelines:

1. Always listen to the customer but the customer is not always right: Do not ever make stuff up. A product manager has accountability across the organization so the sooner you get into the habit of not making stuff up the better.


2. Look for clusters and patterns: This is the art and intuition part. Your job is grok the market. You do that by meeting with customers one at a time but you do not solve an individual customer's problem, you solve the markets problems. Look for patterns, this is where intuition plays a big role. Learn to listen to your own intuition and trust it.
   


3. Collaborate and Communicate: Take the time to earn the respect and trust of your peers and the market, do not assume it comes with the title. The quickest way to get there is to listen and ask others who might know better. For instance you think your product needs better user profile management. A good way to validate this is to ask your support team how many of their customer interactions are around password management and address book management.


4. Do not be afraid of failure: A good product manager focuses on making sure the product being developed is a best-fit for the market needs. This will automatically ensure your individual success but the corollary is not always true.

This is my current mantra and what I call "Evidence based product management".

Caveats:
1. Assumes you are not a brand new start up. If you are one with no customers, then your only guideline is "market research - build - release". Keep doing this till you have enough customers and can extend the hyphen between the three stages.

Time she keeps on ticking...

So here is what is going on.

1. Pretty psyched about this development - We are having our first ProductCamp event in Austin. It is going to be at the St. Edwards campus mid June. Follow this link for details. Seriously recommend this if you are into product management, product marketing or interested in these areas. This is the first of its kind in Austin so you have the opportunity to influence and be involved no matter what your experience level. Show up! and make it happen :-)
2. Yesterday was RSS awareness day. I think it is worth a shout.
   
3. Sometimes all that is required for big observable change is a lot of thinking and researching, not a lot of doing. (Something that all product managers would benefit from remembering)
   
1. Proof - 37signals blog post.
2. Anti-proof - Joel Spolsky blog post.
4. My broken collar bone is healing well. I started hitting the stationary bike at the gym this week. I cannot sprint standing up yet but just getting back on the bike has been rewarding.
   

Product Management and Product Design

This is something I have been mulling over for a little while now.
My company's product management is organized in a classic pragmatic marketing model. This is great! I am serious, i continue to hear horror stories from friends about companies where product management is either in sales, engineering or marketing and thus is subverted for that functional need instead of operating strategically. So I do deeply appreciate my situation.

The only flaw imo in the pragmatic model is that it does not seem to highlight the amount of messiness and collaboration required to design and deliver a good product.

You have vertically focused product managers, technical product managers, product marketing managers, product architects and usability engineers(designers?). These are typical roles that you see in most software companies. The challenge is that none of these roles are responsible for product design. Architects lay out the architecture (duh!), marketing managers lay out the buying process and competitive info, technical product managers drive requirements to engineering and vertical product managers identify market problems and prioritize them. Out of all this information arises a "product" once, twice or 8 times a year... The problem is, a collection of these requirements does not a product design make!

That is like saying an elephant was designed from the need to
a. create a mammal
b. that is a herbivore
c. weighs xx tons
d. has a life span of zz years
e. will occupy a volume of ccc cubic inches and
f. have unique features that permit it to use suction to draw water and dig through roots.

blah blah blah you get it. These requirements above do not capture the zeitgeist of an elephant. So for now I am hoping to design a product intentionally instead of as a side effect. I will let you know how it turns out.

Product Management and market problems

Lunch conversation excerpt:
me: woah.... that is un-freaking believable.
A: You think as a product manager you have an idea of what a product/market problem looks like and then you hear about something like this.
C: Yup it is absolutely true. The chair manufacturers are dealing with this specific problem in casinos.

(C used to be a product manager for a company whose target market is casinos)

So what is the problem -> It turns out that "customers" tend to get so into the games they are playing that they often refuse to get up to use the restrooms. Thus casinos are constantly finding themselves with soiled chairs at the end of the day.

Hrmm I wonder if these customers are wondering if they have a teeny-weeny addiction problem.

Improvements to the world must be highly contextualized

I saw a wonderful video (TED talks) presented by Dr Hans Rosling. Dr Rosling is well known for his unique approach to data visualization. I highly recommend this video.
While it certainly is educational in its core area of poverty, what was truly inspiring to me was how it made me question my assumptions.

At one point in the video Dr Rosling says the challenge he was facing with his students was not "ignorance" but rather "prejudice". This truth applies irrespective of what you do in your life.

Watch this video, it is worth your time :-)

Thought

I see the upcoming Android roadmap as a reality test between two product development/design philosophies.



a. It is important to NOT design by committee and have firm and clear control over the product's form, function and usability. Listen to the market but deliver via a vision. More crudely stated = "Always Listen to the customer but the customer is not always right"







b. Open source philosophies can translate to product design as well as development. I see Android as an example of both form and function going through consensus as opposed to a single point of control/vision. More crudely stated = "Let the market define, design and develop what they want".


I am eager to see where this goes.

Taking Risks

I was having lunch with Rick; one of our development managers (real name used so as to give credit where credit is due). He mentioned that one of his values is to encourage his team to embrace risks.

It was then I realized that I actually was in an organization which was not hypocritical. I had gotten used to working for people/companies which liked the buzz word of "smart risks" but did not quite understand what taking a risk means. In my past experience I was encouraged to take risks as long as we did not lose money, lose a sale or have a bad launch. ummmm hello :-) ...

Anyway, thanks Rick and woot! me that I work in an otufit which so far is rocking hard. I am looking forward to creating products which change lives and delight our market. Anything less is not good enough.

First looks can be deceptive

On first glance this post reads like a damning indictment. On second thoughts it may be a second (most like 999999th) chance for the outlook team. The fact that this user,

1. Continues to use outlook in spite of 67 "known" issues :)
2. Takes the time and energy to document and detail the known issues.

tells me that he gets enough value out of outlook not to walk away in apathy (or might be the company standard, blah blah. I get it I cannot positively conclude that outlook is adding value from this).

My point is simply just that Outlook has done a good job of solving the base problem. It is time for it to catch up with the myriad of usability and interaction issues defined here.

In other words the original user persona defined for Outlook has changed over time and it is the product's responsibility to keep up.

Product Management lessons from watching Season III of Food Networks "Next Big Star"

I just finished watching the marathon new years special by Food Network. They aired the entire season of Food Networks "Next Big Star". I surprisingly got into it. Let me clarify, I am not a fan of reality shows, they seem phony, pretentious, and if anything "un"real to me. They seem as far removed from real life as can be except for the oxymoron categorization. The only reality show I have watched is Project Runway (thanks to my lovely wife) and the season finale of "The Biggest Loser" both Bravo shows. I think I got into "Next Big Star" because it was surprisingly real, and it is to date the most unpretentious and honest reality show that I have watched. I was trying capture the elements that gave it credibility and I think there is a good lesson in product management here.

• Be very clear on your product's core competency - Food Network's product is NOT recipes, NOT travel, NOT anything else. It is television and the way to measure that is audience size and ratings. Their integrity to their product was very compelling to me. This reality show was a clear means to an end -> the end being identify the next personality who will contribute to Food Networks ratings and differentiations vs other TV stations involving food. The contest itself helped with a temporary ratings boost I am sure but the contest was not the end. This is an important distinction to make, with "The Apprentice" for instance the contest is the end and that reeks of make-believe crap. This is why this reality TV is so much better than "Top Chef"(Top Chef of what!?! - this is like getting the "world's greatest dad" mug from your kid and there is no context.)
  

• Make-believe is insulting to end-users. Don't "make" something believable if you can deliver the real thing. I was impressed that the judges for the show were Food TV's Senior VP of Programming and Production and its VP of marketing. These are people whose job it is to grow the product. This made it "real" because in the real world it is exactly these people who would be making these decisions. They did not bring random celebrities to judge the competition or random celebrities to pretend like they understand the product.
  

• You (yes you reading this) are not your product's typical end user: I understand that it is impossible to be a product manager unless you can abstract to some extent but there always will be differences in opinion amongst your user base on all aspects of the product. Accept it, learn from it, and most importantly grow your product through it. This point was struck home for me when I found myself thinking how unbelievably stupid the judges were being in eliminating Amy and retaining Jag and Rory. I was pissed! but thinking on why I was getting so pissed was what led to this point.
  

• Be prepared to be flexible: The judges thought they had picked the best two contestants for the finale (Jag and Rory). Jag was eliminated since he had fabricated history and so it was Rory vs Amy and Amy won. *knock knock* - man these guys are lucky. Americans picked the contestant they had previously eliminated (further confirming my instincts *grin*). Of course hindsight is 50/50 but my point here is that they responded to Jag's revelations admirably and ended up doing a better job than if there had been no bump in the road.
  

Any ways :-) I enjoyed this a lot. Happy 2008 to you and all your loved ones.