My Innovation Hashtag Cocktail

I just created an “Innovation” tab in Hootsuite. In it, I have the following hashtags:

#prodmgmt – I’ve been following this hashtag for some time and it’s got great tweets by product management experts.  A great tweet came through from @stempm – “#prodmgmt is not a profession – it is a way of life!”  I totally agree with Irina–product management is the practice of creating value through providing offers to customers.  This is not just a position in a company, those of us that are value creators all follow product management practices.

#innovate – Obvious reasons.

#agile – Although this is mostly used in a software development context, agile concepts are key to innovation: quick development cycles, market testing, responding to change.  I’m also a fan of Lean development and business processes.  I thought that #lean would be a good hashtag to watch, but it seems a bit noisy.

#startup – Great stories and interactions here around startups (obviously).  Not to say that only startups are innovating, but I would say you’re more likely to see new and disruptive innovations coming out of startups than you would with established companies (see Clayton Christensen for details).

#justlaunch – This isn’t a well-established hashtag, but I would like to use it to engage on the idea of getting out of your own way and “just launch”.  If you’re an entrepreneur with analysis paralysis, this is your 12-step program to #justlaunch.

#createvalue – Again, not a well-established hashtag, but I would like to use it to engage on the idea of creating value.  There are lots of products out there.  There is a lot of money changing hands.  But, is there a lot of value being created?  Do you think investing your money in the stock market is creating value?  How are you creating value today?  I believe that creating value is why we get up in the morning.

Why only 6 hashtags?  That’s all that will fit on one screen without scrolling.

Happy Friday!

Learn Architecture, not Bricklaying

I started programming when I was in high school.  I learned about computers my junior year and decided to take a programming class.  Programming came naturally to me—I’m one of the lucky ones.  In college, I majored in computer science at UC Irvine and started my career as a software developer.

Since then, I’ve worked as a consultant, project manager, and eventually a product manager.  My background as a “classically trained” developer has been extremely helpful to me as a product manager.  Although I don’t do much programming anymore (at least professionally), I’m able to use my experience to understand how a product should be developed and whether or not best practices are being followed.

So—if you’re a product manager and do not have experience developing software, should you learn how to code?

I argue that your time would best be spent learning software architecture and design concepts first (higher level), instead of learning how to code (lower level).  This would give you the tools to have deeper conversations with your development staff and also help you short-circuit iterations where requirements meet specifications.

Here’s a story to illustrate: I was on a project where we wanted to enhance our file importer product by allowing it to automatically rotate images if needed.  Although this was the only requirement at the time, I could foresee that we would eventually want to support different “pre-processing” operations like parsing a metadata file for information, or rearranging the order in which the files were imported.

By understanding the concept of decoupling, I was able to help design a feature by which we created an API that we used internally (to do the automatic image rotation) but also allowed developers to create their own pre-processing operations.  This made the product much more flexible and maintainable (fewer code paths to follow) and our customers, partners and professional services staff loved it!

To start, I would suggest learning some basic concepts around object oriented programming like: Decoupling, Abstraction, and Separation of Concerns

I would also recommend the following books (try to stay high-level and focus on architecture/design concepts):

Code Complete: A Practical Handbook of Software Construction, Second Edition

The Pragmatic Programmer: From Journeyman to Master

Design Patterns: Elements of Reusable Object-Oriented Software (aka “The Gang of Four”)

Learn some of these concepts and see how they improve the conversations you have with your development staff and how they will help you craft lower-level requirements.

Good luck!

9 Ways to be a Product Management Hero

Product Managers have the unique role of driving the development of products within a company, which has been and continues to be the source of value and wealth creation in the high technology field over the last several decades.  If you are a Product Manager, here are nine ways for you to be a hero for your product development team.

One: Know the Difference between a Requirement and a Specification

A requirement describes need, while a specification describes system behavior.  Requirements must drive specifications.  When you find yourself looking at a specification and asking yourself “why do we need to do this?” typically you will find that the requirement was not clearly defined.  To be a hero, you must know this difference and fight against specifications that don’t have clear and rationalized requirements backing them.  Specifications without requirements are a waste of time.

It’s easy for Product Managers (and others) to mix this up.  I think this comes from the tendency of people to think visually and focus on concrete enhancements to the product as opposed to the underlying need, which can be fairly abstract.

Two: Tell Stories about how the Product is being used

Engineers want to know that their work is valued and the best way to let them know is to tell them stories about how the product is being used.  Tell them about how the key feature they worked so hard on is saving customers’ time, helping them do their jobs more effectively, helping them be more competitive, etc.  Stories like this may even clue you into unintended ways the product is being used and help you preempt issues that might come up.

If you don’t have good customer stories to tell, get out of your office and talk to some customers!

Three: Take Responsibility for making Tough Decisions

Should we drop Feature A in order to make our ship date?  Should we fix this critical defect and risk delivering on time?  This feature should work this way, but the VP wants it done his way—what should we do?

A heroic Product Manager gets in front of issues like this and takes responsibility (and possibly a bullet) and makes a decision that is best for the company.  You fight whatever political battles need to be fought and you shield the product development team if at all possible.  These are the moments that define your career as a Product Manager—seek them out and take advantage of them.

Four: Help them Navigate Office Politics

Most engineers don’t like to deal with office politics (or at least the majority of ones I’ve worked with), and usually don’t have the depth of experience Product Managers have while working in a cross-functional environment.  You make a living on getting things done through influence, not reporting lines, so you’ve got tremendous insight into what makes people tick.  Help guide your engineers through the murky waters of office politics—even when they have to deal with their own boss!

Five: Establish a “No Broken Windows” Policy

The Broken Windows Theory implies that behavior is significantly affected by one’s environment.  This theory has been used to rationalize the crime epidemic in New York in the 1980s.  The idea is that something as simple as a broken window provides a “signal” that disorder is tolerable, which may escalate to trash being left out, broken bottles left on the street, vandalization, theft, etc.

This concept very much applies to product development.  If you allow “broken windows” to exist like misspellings in screens and messages, misaligned user interface elements, and unhandled exceptions, you send the signal that the product is not being cared for and the quality of the product may fall off a cliff.  This applies to the internal code as well—you shouldn’t tolerate “spaghetti code”, untested modules, or even deviation from naming conventions.  If the product is pristine inside and out, everyone on the development team will treat the product with respect.  Be sure to partner with the lead engineer to drive this policy inside the code.  Be aggressive with fixing any broken windows, regardless of how small the issue might be.

Six: Understand how your Decisions impact Support and Maintenance of the Product

File this under: Not the most fun part about Product Management, but it is part of being an adult.  Support and maintenance can make or break a company.  It’s better to have something that is less functionally deep and easy to support and maintain than to have something ultra-flexible but impossible to support.  Spend some time on technical support calls to get a sense for this.  Remember that you must look at both the revenue and cost side of the equation when you make product decisions.

Seven: Help Engineers realize that the best Business Decision is not always the best Technical Decision

There will be times where you have to make decisions based on business constraints, where these decisions conflict with technical purity.  One classic example: When to stop testing.  Theoretically speaking, it is nearly impossible to have complete test coverage.  In an extreme example, you can run user acceptance tests for every individual user your product will ever touch.  If you do this, you would have significantly fewer defects once you shipped, but the problem is that you would never ship!  When you make decisions like this, be clear that you’re doing so out of business necessity and acknowledge that the decision is not the best technical one.

Eight: Get them all the Tools they need to Succeed

Nothing is more frustrating than being tasked to do something and not having the right tools to do the job.  A heroic Product Manager goes to battle—begging, borrowing, and stealing in order to get his or her team these tools.  Use your influence and political savvy to get what you need.  If you have the privilege to work on a high-visibility project, use this opportunity to pressure management to give you the resources you need to succeed.

Nine: Challenge them to build Something Special

We all want to be a part of something special.  For those of us in high technology fields, we are working in exciting times.  The speed of innovation is tremendous and we have the opportunity to reach so many people and positively affect so many lives.  Use this opportunity to inspire your product development team to build something special—something they can look back on and be proud to say that they were a part of it.

Is There Power in Your Roadmap?

During one of my first commutes from Irvine to LA for my current gig, I listened to a podcast featuring Geoffrey Moore, where he discussed concepts from one of his newer books, Escape Velocity.  The core of the book is about a company’s “power”, which is a condition or position of a company which allows it to execute.

One of the profound concepts is this: Power fuels Performance and Performance consumes Power.

However, most organizations don’t have a good vocabulary around power, so all they talk about is performance.  In fact because of this, most organizations incentivize and reward performance, but not replenishing power.  This causes a problem where companies may find themselves consuming their power without replenishing it, resulting in their eventual inability to perform.

When I first listened to the podcast, much of it went over my head, so I bought the book.  A very clever piece of marketing by Mr. Moore, I might add.

Moore only had an hour, since the podcast was recorded from a live session with Stanford students as part of the DFJ Entrepreneurial speaker series.  During this hour, Moore started with his big idea, discussing why power is so important and why companies don’t manage it correctly.  He then engaged the audience to think of themselves on a Board of Directors or a CEO of a company and discussed concepts like Category Power, Company Power, and Market Power.  He then shifted gears and engaged the audience to think of themselves as Product Managers–this is where my interest was piqued.

Moore brought up an interesting point: Product Management in the high tech industry is probably one of the most important roles because as a product manager, you have your finger on the pulse of the company.  You are driving the offers of the company, which directly impact the company’s ability to earn revenue.  The remarkable thing about this is that most product managers serve in this role within the first 10 years of their career (which is true in my case).  So, if you’re a product manager, you should consider it an amazing privilege to be in that role.

I listened to this podcast again more recently and I reviewed the Offer Power chapter in Escape Velocity, and I found that the concepts Moore presents are extremely relevant when it comes to creating a roadmap.  His chapter on Offer Power discusses three types of innovation.

Productivity Innovation: This type of innovation (product, process, or otherwise) is designed to “free you from the pull of the past”.  This allows you to free up resources that are currently doing unproductive or ineffectual things that are sucking up time and other resources.  An example here might be to do some code refactoring or reducing surface area of a product.  You want to use Productivity Innovation to fund the following two types of innovation: Neutralization Innovation and Differentiation Innovation.

Neutralization Innovation: This type of innovation is basically playing “catch up”.  Your competition has feature X and you don’t (to an acceptable level), and in order for you to compete, you need “good enough” feature X.  This is extremely important because if you don’t neutralize, you can’t compete, and all other efforts are wasted.  This is probably one of the most boring types of activities, but you do it because you have to (it’s part of being an adult).  Note that “good enough” is extremely important.  You don’t need “best in class” feature X–just good enough.  Moore posits that customers don’t pay a big price premium for “best in class”, but only some increment over the mean.  Customers pay a big price premium for “beyond class”, which is what you’ll get if you execute Differentiation Innovation correctly.  A popular example here is Microsoft Internet Explorer 3.0 neutralizing Netscape Navigator.

Differentiation Innovation: This is why you get up in the morning.  What makes you different?  What is your core value proposition?  This type of innovation is designed to break you away from the pack.  This type of innovation creates value for your customers and you should be 10x greater than your competition in this area.  This is a very asymmetrical bet, which is what makes it scary.  As Moore put it: You’re putting all your chips on one square on the roulette table.  You may not win, but you will get noticed.  A popular example here (and not using Apple), is Salesforce.com providing 10x greater benefits around software installation and operating costs for customers due to its hosted software architecture and Software as a Service business model.

From an execution perspective, you should fund Productivity first, in order to free up resources.  You should then fund Neutralization in order to achieve parity with your competition.  You then must fund Differentiation in order to create that next-generation offering that will make you “beyond class”.

So when you plan activities and features for your roadmap, I’ve found that categorizing features against these different types of innovation and identifying the (rough) strategy of “Productivity before Neutralization before Differentiation” to be very effective.  Not only does it give stakeholders a clear vision of purpose for the activity and help you rationalize feature priority, but it puts you in the best position possible to create that next-generation offering that will make you “beyond class”.

Good luck!