Google’s Mission: Right or Wrong?

August 30, 2011

In my last post, Are People Buying What You’re Selling? I discussed mission statements and vision statements. The act of creating these statements – good ones – forces you to think deeply about your business, capturing the essence of why people should do business with you and why they should come to work for you.

These should be crafted with a long-term view, but are there times when that view should be trashed, or at least modified? Let’s look at a high-profile, public company: Google.

Google’s mission is to organize the world‘s information and make it universally accessible and useful.

As the world’s leading search engine, I would say that they’ve certainly succeeded on this front. But Google has a problem. Steve Denning recently wrote about this in a two-part article urging: Google: Rethink Your Mission! (And Part 2: Google+)

Are People Buying What You’re Selling?

August 26, 2011

As a leader, that is. Does your strategic vision sound something like this?

“Our strategy is to develop products that truly fulfill customer needs by exploiting our skills and abilities to the maximum level in order to provide a maximum profit to our shareholders. We will do this with high-quality products that provide a substantial competitive advantage. And while achieving this, we will be supportive of our community and our employees.” (Product Strategy for High-Tech Companies, created from the Dilbert Mission Statement Generator that is sadly no longer available.)

Granted, the example above isn’t from a real company, but elements of these generic statements find their way into a lot of real vision or mission statements. If any of these sound similar to your company, ask yourself this: What do your customers or employees really understand about your company? What is it all about? In other words: What do you stand for, and why aren’t you clearly communicating it?

Expect Mistakes in Business

August 23, 2011

Great professional sports teams are intolerant of mistakes – during a game. They’d much rather make their mistakes during practice. And if they do make a mistake during a game, they want to learn from it and avoid making it in the future.

Various professions have moments when mistakes aren’t tolerated, either. Doctors, for example, strive to be mistake-free during activities like surgery or delivering babies. While I’m not a doctor, I’m sure that the demands of the moment do plenty to increase concentration. Between that and years of training, mistakes are kept down to a rare occurrence. I’m equally sure that in other aspects of their job, doctors can and do make mistakes. The level of concentration required during surgery or delivering babies is not sustainable hour-by-hour, day-by-day.

In business, the “game” is continuous; we don’t have the luxury of practicing more than we play like sports teams; quite the opposite, in fact. And while we all have our peak moments of high concentration and involvement, we can’t sustain that pace indefinitely any more than doctors can.

Book Review: The 42 Rules of Product Management

August 19, 2011

42 Rules of Product Management: Learn the Rules of Product Management from Leading Experts "from" Around the World The 42 Rules of Product Management is a collection of “over five centuries” of product management wisdom from a variety of product management experts. Each chapter – from a different contributor – is consequently a fresh perspective provided in a short, concise chapter.

As a new product manager, I enjoyed gleaning insights from a variety of perspectives (the contributors include executives, consultants, authors/bloggers, and trainers as well as product managers). I appreciated reading what each contributor felt was important about product management, and why. It gave me a broad perspective in a short amount of time, and I found myself plowing through the book very quickly.

In this post, I'll share some nuggets that I came away with.


August 16, 2011

I’m celebrating my 50th birthday today! It doesn’t seem possible, but I’ve lived a half a century already...

I was a kid when the original Star Trek series aired on TV. My parents took me and my brother to the Cinerama airing of 2001: A Space Odyssey – but I wasn’t quite old enough to appreciate it. I also remember my parents waking me up to watch Neil Armstrong step out onto the lunar surface.

Define the Problem, then Resolve It

August 12, 2011

When you or your organization encounters a problem, does everyone start generating solutions? How do you evaluate which one to choose?

Choosing can be difficult, particularly in software development where problems are inherently complex and dynamic – involving both people and technology. But there is way around this.

Albert Einstein is attributed to providing an interesting answer to the following question: “You have one hour to solve a problem; how do you proceed?” His answer was reportedly, “I would spend fifty-five minutes defining the problem, and five minutes finding the solution.”

Make Improvement Continuous, not Periodic

August 9, 2011

“At regular intervals, the team reflects on how
to become more effective, then tunes and adjusts
its behavior accordingly.”

Agile development seeks to change the working world of development teams for the better, and it does. When it comes to making improvements, the retrospective approach used by a framework such as Scrum is a great start, but it still smacks of being a periodic improvement tactic versus one of continuous improvement.

You Can’t Cut and Paste Your Way to Improvement

August 5, 2011

Jeff Atwood recently wrote about how Nobody's Going to Help You, and That's Awesome, differentiating between self-help and self-improvement. As Jeff says, “Reading books, blogs, and newsletters by people who have accomplished great things is a fine way to research your own path in life. But these people, however famous and important they may be, are not going to help you.

He’s right, you have to help yourself. Just like cutting and pasting text isn’t writing, “cutting and pasting” advice from a book into your life or organization won’t provide magical benefits. There is change involved, and lasting change requires time and effort. You have to work at it.

Iterating is Costly

August 2, 2011

Agile development’s iterative philosophy sounds great: deliver working software in short periods of time (weeks), allowing the users and/or stakeholders to review the work and suggest changes. These changes get prioritized and incorporated into the team’s product backlog. If the changes are important enough, they get worked on in the next sprint (iteration).

So you iterate. The problem is, iterating is a rework strategy. If you are iterating, you are increasing the number of increments required to deliver the forecasted feature set.

As a new product manager, I’m in the process of recommending a change to one of our products under development. I found what everyone agrees to be a serious limitation, one that is going to cost us several weeks of rework to correct. A change like this introduces a certain amount of organizational anxiety, and it certainly torpedoes the timing of other go-to-market planning already in progress. People are grateful that I uncovered this issue, but no one likes making the payment.

How do you avoid this problem?