1. Spotting new business opportunities and threats.
2. Iterating and innovating on the core product. Creating new solutions to old problems.
3. 'Steadying the ship' and spreading the love. Keeping customers and stakeholders happy (in that order.)

Nothing much changes regards the essence of product management and development. At it's heart product management is a cyclical process, the key tenets being those listed above. The cycle may well widen, but essentially, what we focus on remains the same.

So, if you feel like a hamster on a wheel in 2010, it's because you are!

Happy New Year fellow hamsters!

Carl

'Seeing the whole,' or being a good strategist and leader, are the most important aspects of being a successful product manager.

It is hard to summarise what great product leadership and strategy is so I’ll start my post with my thoughts on what it is not:

• Getting stuck in tunnel vision. Time and time again product managers suffer from fixating on an undeserving aspect or feature of a product. Ask yourself, regularly, is their value in what I am currently doing? If there isn’t, focus on something else.
• Not recognising when a problem is solved (related to the above.) Some problems need a simple solution, don’t overcomplicate them.
  
• Discarding planning. Working agile is not an excuse not to have a plan. You sooo need a course or a mid- term plan. If you don't, the chances are you will slip in to tunnel vision and by extension overcomplicate things.
• Going it alone. Sometimes this is appropriate but more often than not, it isn’t. Product roadmaps must be tied and woven to overall business strategy and goals. Product management is not about coming up with your own ideas and implementing them. We all know there is nothing more horrible than a vanity project or product.

Conversely, here’s a few of my thoughts on what great product leadership and strategy is:

• The ability to create a vision and define a product to be built. In essence, this is what product managers are there for.
• The ability to plan, prioritise and deliver the vision. Sounds straight-forward, but it is the mixture of visionary and delivery ability that make product managers so important in businesses.
• The ability to assess success and failure and treat them with equal vigour. Product managers need a natural instinct to step back from a product and see it for what it is. If a product is on vision, is succeeding, great. If it’s failing, this should be clocked and dealt with swiftly and appropriately.  
• The ability to continually spot new opportunities and weave them in to your vision. (Not to be confused with scope creep or ideas for ideas sake, all of the above points need to be considered.)
• Finally, products are all about people. People build and use products. You want both the people you work with and your customers to be happy. You are dreaming if you think you can sustain products without having both!!

That’s it. Can you 'see the whole?' Be interested to hear your thoughts on this one...

• NEVER delivered anything like this product before. Transactions, currency, 'banks,' net income statements, gazillions of security features, consumer 'trust' issues. That's before you get in to features, usability blah blah blah.
• A third party was involved.
• Pressure. Pressure to 'get it right.' It's a niche and innovative service that simply has to 'work' for our customers.

The single guiding principle for tackling a 'largish' project like this has to be: 

• Control scope. 

When controlling scope you have to decide:

• What's the core idea or principle for your product?
• What's the minimum functionality required to fulfil this core principle or idea for your product? (Note: I don't mean for Beta, I mean to actually ship a formed product.)

Once you know this, moving forward to a release is made so much easier.

That's it. That's the point I felt worthy of scribing. Defining scope and keeping scope in sight is key.

Any thoughts on the brand spanking new online banking service are very very welcome, I'd love to hear your thoughts. In particular, of-course, do you agree with my point on scope and did we get the scope of the online banking service correct for this new release?

• The software/website/thing being released is in a test phase. There may well be real concerns over whether the software/website/thing - is actually stable. 
• The software/website/thing being released isn't all there yet. It isn't fully formed, or it doesn't quite have all the components or functionality it was required to have.

But, in recent 'internet times' the term Beta has become synonymous with a load of other things, most notably:

•  Glamour. I think people in the internet community have come to love the term. Having a website in Beta is seen as fashionable, no doubt about it. The term is used with the mis-guided (in my view) perception that it will, in itself, create excitement and buzz around a product. Or maybe it just makes people feel clever? Honestly, I'm not sure anymore.
• Pretty lame marketing tactics.Related to the above, the marketing ploy you see used is attempting to cash in on the promise of being privy to something really great, FIRST. Beta is very often now used as a viral method of attracting early adopters and generating referrals/word of mouth. Though there is nothing really wrong with this, and it can be really successful, I think metaphors for 'Beta' inevitably get mixed and confused.

In my view, the plain truth about most releases on the web is that they are just, well, NEW. Further to that, I think we should generally be more confident in the scope of what we release and leave the consumer to decide whether this product is indeed new, exciting, glamorous, worth telling friends about - all those things the more contemporary use of a 'Beta label' seems to want to claim.

So, when thinking about releasing the question is not: Shall we put our product out as a Beta release? It's really more answering the question: What's the minimum I can have to release my product and be happy?

Unsurprisingly, in answer to the ultimate question: to Beta, or not to Beta? I'm going to have to say; not to Beta.

What would you say? I'd really love to know what you think on this subject...

1) There's nothing negative about innovation in a corporate/business context.
2) There's nothing negative about making a big deal about innovation in a corporate/business context.
3) It's OK to say you belong or reside within and have an innovation team within a corporate/business environment. Innovation is not a dirty word.
4) Creating processes to support innovation in a corporate/business context is not done to, nor should, promote elitism. Quite the opposite.

Overall, it has to be that innovation has a far more practical place within corporations and businesses.

Some observations:

• It's OK to have an innovation team. You have a finance team. It's really no different. I am as confident I can organise my finances as well as our finance guy, but obviously I appreciate we need someone thinking about that stuff all the time on a business level. The finance guy doesn't stop me thinking about finance. Innovation is no different.
• Innovation as a discipline and job spec. There are a few sustained qualities required by innovation. If Innovation were a person, that person needs to be a great networker, have bags of perseverance, be not afraid of experimentation,  be happy (and naturally) question status quo and (crucially) understand the business, what it is trying to do and make associations between different situations and find solutions.
• Innovation and ideas generation. Sure, the innovation team would come up with ideas, duh. But, it is also about capturing and encouraging the development of creativity and ingenuity with whatever person, unit, team or outside influence it comes in to contact with. Your innovation team, if it is a real innovation team, will find a way to empower change and promote ideas from all over the place.
• Innovation and strategy. Products without business cases or strategies are not products, they are projects, ill defined projects. Obviously, innovation has to be strategic and think strategically. Innovation for innovation sake is not viable (mostly), in a corporate or business context, so innovation has to be channeled. It has to fit. There's a gap that needs to be laced up between strategy and innovation, and the innovation team are the ones who should tie the knots.
• Innovation and R&D. R&D is clearly part of innovation, and another very practical reason why you need a team or persons on it. Thinking 5 years ahead on the web is terrifically hard. but seriously, a year ahead should be an ongoing and consistent thread of exploration, theorising and most importantly, visioning.
  
• Innovation and delivery. This comes back to innovation as a discipline. Bottom line, creative ideas that aren't realised are worthless. Another reason to look at how you ring fence persons for innovation.

Lastly, it's pointless to fear innovation, its challenges and what it entails.  Treat innovation the same way as going to the office kitchen. Keep it practical, anchored in the here and now. I'm actually off to the kitchen now. Cup of innovation anyone? It's my round...

(When I get back with my coffee I'd really like to here your feedback on this topic. Particularly on where you think innovation should sit within businesses and corporations?)

Good product managers need to be able to think with clarity and stay on top of things. You simply can't do this if you are stressed-out and tired.

So, how do you stay 'fresh?' Here's what I think:

• Don't think about your product all the time ( another crap piece of advice from a 'trainer.') A broad interest in technology and 'stuff' will help you more in the long-term than obsessing about your product.
• Look after yourself because your product will not. Eat well, exercise and indulge your passions and interests.
• Get some ZEN ( easiest way: read Tabita Green's excellent blog.)
• Focus on what's important, drop everything that isn't. If you can delegate, do.
• Laugh. We are the lucky ones, we have jobs with prospects. Enjoy it.
• Take a break, small one's, through-out the day.
• Take a break, long one's, whenever you can!
• Challenge yourself. Solving new problems is cathartic (err, if that's the right word.) Stagnation simply isn't good.
• Don't take it all so seriously, lighten up! The world still revolves without you and your product.
• Change environments. Work remotely, change your journey to work. Change is often as good as a break! (so they say.)

Love to know what you think? How do you stay 'fresh?'

Attempts to register users for stuff can be seen as quite a sceptical move. We'd argue (obviously) that this is not in this case. We see it that we are not compromising the ability for individuals to continue to use our site not registered, merely making it explicit that we don't think we can serve you as well as a customer if you don't register.

We dwelt on this a fair while and it got me thinking about the general question of whether it is OK to put up certain barriers to entry for your product? I maintain that the answer to this question is YES (with a few caveats.)

Caveats:

• There has to be a clear customer benefit.
• You should provide a basic experience without barriers to entry.
• Keep barriers small and pain free.
• Make sure a sound rationale for constructing a barrier to entry is in place. Your customers are probably cleverer than you and will suss it out quick if not.
• Review your decisions, but stick to your guns, you have to make a living from your product.
• Explain your reasoning and create an open dialogue with your customers with the changes you make.

If, like us, you go to the effort of 'sexing up' a barrier to entry like registration, I'd suggest keeping these things in mind. 

Am I right here? Would love to hear your thoughts on this one? (And, if you have time, what do you think of the new lovemoney.com site design?)

Office politics are terrible for your product.

Product managers must try an operate under the radar of politics. Politics don't make good product decisions, instead they distort the clarity of your product vision and can massively impact the successful development of your product. (If you let them.)

So, how does the product manager ride the wave of office politics and arrive on the shore, nice and dry? Here's a few points from me: (but I'd love to know your take on this subject!)

• Openness is key. By keeping the product an open book you avoid controversy, and by default, 'some' politics.
• Keep your product strategy focused on the customer and commercial sense. Always.
• Shield the product team. As a rule, politics are extremely confusing and de-motivating for development teams.
• Be prepared and accepting of politics, but, don't prepare your product for politics.
• Develop a thick skin, remember products (and you) are judged on success - nothing else.
• Smile. Politics is meaningless and intrinsic in life. Don't let them get you down.

As I mentioned, I'd love to know how you view and deal with balancing the product and politics? (I am sure we could all use the help!)

• Product features sneak in from nowhere.
• You are fire-fighting, constantly.
• You're having lots of meetings that really don't help you.
• You don't get time to do 'your stuff.'
• People ask you questions about your product and you don't know the answer.
• You're not in love with your product.
• You're not spending enough time with the team who actually 'builds stuff.'
• You're waiting for someone else to make a decision.

How to stop co-ordinating and start conducting:

• Get some fresh ideas for your product.
• Cultivate informed opinions about the direction of your product.
• Focus on the product and your own productivity (this could mean saying NO more.)
• Grow some balls and be confident.

That's it, small point, but an important one. As always, agree? - dis-agree? Either way, I'd love to know...

...they gather business requirements,
...they review analytics,
...they engage in user feedback,
...they listen to colleagues, friends, family,
...they carry out market and competitor analysis,
...the list goes on.

Something that can get overlooked though, and overlooked at peril, is leaving or creating time to harvest an opinion. Any or all of the techniques and processes I listed can be successfully completed by any individual. Where the product manager triumphs is using a mixture of information and judgement to define the product to be built. So, do everything you know you should do. Then, put it to one side. Let what you've learned inform your decision. BUT, draw conclusions yourself.  The success of your product will inform you of whether you made the right decisions, nothing else. So, do make sure your decisions are informed. But, above all, make sure they're your own.