Entries Tagged 'Strategy' ↓

TED: Bob Corrigan – Building the Encyclopedia of Life

Bob Corrigan is the director of product management for the Encyclopedia of Life and has been a regular in the product management community for years. So today I offer you a Youtube-based TEDX link today… Bob’s presentation for TEDxMidAtlantic this past year (2011) Building the Encyclopedia of Life

I am so happy he did this and I highly recommend you watch it.

Any suggestions for the next one?

More Strategic. Just More.

It was a fun conversation on Tuesday. How can you distinguish between a Senior Product Manager and a Product Manager? There was a side-hall conversation on the topic with some Twitter people too.

First conclusion, it is not based on experience. Experience might lead to it, but you are not a senior product manager because you have been a product manager for X years.

Second conclusion, it requires a broader vision. Someone who is capable of thinking about “the many” versus “the one”.

The third variable (note, not conclusion) is that a senior product manager is “more strategic”. I really struggle with that. If you are strategic, can you be more strategic? Does having more responsibility make one more strategic? Not sure. Seems like I am applying the same concepts to a broader set and not sure that makes me more strategic. However, it ties back to the second conclusion and that would make one senior.

More food for thought.

Professional Thinker

thinkerFor the past few months (nearly 8 since I made the western move) I have been making the rounds and meeting lots of new people. With that comes the inevitable question “What do you do?” Depending on who they are and what I think their background is, I will vary my answer. Sometimes it is “I am Senior Product Manager for software company based downtown” or “I work for a software company” or “I am in product management” and the list could go on using various descriptions to articulate the same thing. Generally, this spawns a series of “and what does that mean?” questions for which I have another series of canned answers.

One particular occurrence, when asked by the resident 12-year old “What do you do?”, I responded with “a professional thinker” and it got a curious look and a bit of chuckle. The reality is, this is pretty accurate. What we do, as product managers, is think. In my post “10 Secrets to GREAT Product Management“, the fourth item is “think”. We are paid to think. We take input and think about it. We create output and collect more input and think about it some more. (Ideally you write down your thoughts using various best-practice techniques.) Some times there is short-term thinking (today, this week, this sprint) and some times there is long-term thinking (next sprint, next year, 3 years from now). Business thinking. Technical thinking. Financial thinking. Creative thinking. The challenges are blocking out time for thinking in your schedule and not over-thinking things.

I like to tell people that product management is a knowledge worker role, a linchpin role if you will. For those of you who have not yet read Linchpin by Seth Godin, a linchpin is defined as: “… people who invent, lead (regardless of title), connect others, make things happen, and create order out of chaos. They figure out what to do when there’s no rule book. They delight and challenge their customers and peers. They love their work, pour their best selves into it, and turn each day into a kind of art.” Sound familiar?

Thinking is only one of the many things that you do through the day/week/year, but it is one of the more important things.

So for the time being, I am running with this “Professional Thinker” title. Combining that with “I am thinking of my equivalent to the iPhone 5″, it seems to resonate with people. They may not know how I do it, but they know what I do.




If you enjoyed this post, please leave a comment or subscribe to the feed to receive future updates. You can also follow me on Twitter. Tell other people about this post.


IBM 2010 Chief Executive Officer Study

Reference: IBM | 2010 Chief Executive Officer Study

Lots of good bits in this survey. It is quite long though. Here are some of my favourite thoughts.

Standout CEOs expressed little fear of re-examining their own creations or proven strategic approaches. In fact, 74 percent of them took an iterative approach to strategy, compared to 64 percent of other CEOs. Standouts rely more on continuously re-conceiving their strategy versus an approach based on formal, annual planning.

Creativity is the most important leadership quality, according to CEOs. Standouts practice and encourage experimentation and innovation throughout their organizations. Creative leaders expect to make deeper business model changes to realize their strategies. To succeed, they take more calculated risks, find new ideas, and keep innovating in how they lead and communicate.

….. and many more ….

** Standouts are defined as: Long-term performance included four-year operating margin compound annual growth rate from 2003 to 2008. Short-term performance included one-year operating margin growth rate from 2008 to 2009. This allowed us to identify “Standout” organizations that were able to improve operating margins both long term and short term.

Reference: IBM | 2010 Chief Executive Officer Study



If you enjoyed this post, please leave a comment or subscribe to the feed to receive future updates. You can also follow me on Twitter. Tell other people about this post.


10 Must-Read Articles from Harvard Business Review

10 Must-Read Articles from HBR (PDF)
10 Must-Read Articles from HBR (Source)

Enjoy!

Anyone want to summarize one of the articles for the community?

If you enjoyed this post, please leave a comment or subscribe to the feed to receive future updates. You can also follow me on Twitter. Tell other people about this post.


Harvard Business Review’s Must-Reads on Strategy

This link is courtesy of Jeff Lash of How To Be A Good Product Manager fame.

Harvard Business Review’s Must-Reads on Strategy (PDF)

Enjoy!

If you enjoyed this post, please leave a comment or subscribe to the feed to receive future updates. You can also follow me on Twitter. Tell other people about this post.


Using the Roadmap for Planning and Selling

I received another request in my “suggest a post” area (thanks!).

The use of the Product Road Map for internal planning vs in support of the selling process?

I am going to make one assumption that the author of this suggestion is referring to the external sales selling process and not an internal selling process (i.e getting roadmap buy-in).

In my opinion and I think everyone else will agree, having a roadmap for internal planning purposes is not an option. It is mandatory! The roadmap for selling is generally frowned upon.

Roadmap as a Planning Tool

Some of this is rehashed from previous posts, but your roadmap is your strategy. It is your long-term plan for success. It’ll contain the details of your value network, vision and mission statement.

I know, I know. Typically your roadmap is a power-point presentation or a spreadsheet, but it is time to mature that process. Your roadmap should contain descriptions of your partners, your buyer and user personas. It should contain describe your vision and the plan to to achieve that vision. (Unless you are a single product company you will want to provide some additional commentary on how this vision helps the company achieve their vision.) Typically, this plan is described with your release plan for the short term (less than 12 months), a feature plan for the longer term (more than 12 months) and any business development plans. Your mission statement defines your product’s purpose and primary objectives. Its prime function is internal – to define the key measure or measures of the product’s success. I have written in the past about metrics. Everything should be written using a language that shows alignment across your value network, vision and mission.

As you can see, the content is driven from the planning for your product. The nice thing about using a roadmap, is that it allows you to bucket all your strategic thinking into one document.

Roadmap as a Sales Tool

Now despite the comment above that using your roadmap as a sales tool, you will sometimes not have a choice. Prospects may want to see your vision. You’ll need to make everyone aware the risks with showing prospects the roadmap. It could delay the sales cycle if they wait for future features or set poor expectations if they believe the roadmap will not change (and it will change). There is nothing wrong with sharing your vision, but the appropriate expectations need to be set for the Sales team and the prospect.

If you enjoyed this post, please leave a comment or subscribe to the feed to receive future updates. You can also follow me on Twitter. Tell other people about this post.


Budget and your Strategy

I suspect that one of the major impacts to your roadmap is a budget change. And by change, I mean a reduction in available funds for product development. I suspect a lot of you dealt with this last year as you suffered through many rounds in workforce reduction. I am curious how you handled that.

Picture this scenario, late last fall you reviewed all your feature requests, dusted off the roadmap, the business case is shiny again and it is all aligned with your vision and the corporate vision. With your budget approved, you are ready for 2010. Enter January 2010 and due to slightly missing the Q4 numbers you are now forced to chop $75,000 from your budget. Basically the equivalent of one developer. What do you do?

  • Band together with the other product lines and pray for Management to realize that chopping 75k is guaranteed to affect more than 75k in revenue this year?
  • Offer to combine forces with another product to share revenue (knowing that you will likely never be able to undo this) in hopes that your new increased revenue will offset your requirement to reduce cost?
  • Suck it up, chop the developer and leave the roadmap unchanged and modify the business case (i.e. budget) to reflect the reduced cost but leaving the revenue numbers unchanged? The more with less scenario or in this case same with less.
  • Suck it up, chop the developer and scale back the roadmap and business case (i.e. budget) to reflect the reduced cost and revenue numbers?

I am less inclined to do anything that will affect revenue for future years. Depending on how many rounds of workforce reduction you have survived, I am less comfortable selling the same with less scenario. If you are in your first or second round, go with that. Teams generally perform better after the first and second cuts. I am not hopeful they will “see the light” and let you keep a full team in hopes of achieving your revenue targets. Although, this is probably the scenario I start with. Sell the vision, sell the facts and get buy-in on the business case. Failing that, cut, reduce and move forward.

I am hopeful someone will share a situation where a budget cut has affected their roadmap and how they responded.

I meant no offense to any development types by suggesting we cut you, it was a just a random example. We really hate cutting our roadmap in any scenario.

If you enjoyed this post, please leave a comment or subscribe to the feed to receive future updates. You can also follow me on Twitter. Tell other people about this post.