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.

As Simple as Square

I’m not in Square’s target market segment, but I’ve been on their bandwagon for some time.  I love their concept and execution.  After reading this interview with CEO Keith Rabois, I’m getting myself a cushion and cup holder for my seat on the bandwagon and will be making myself comfortable.

I’ve highlighted the quote that resonated with me the most: “… there’s strength in crafting an entire experience.”  It sounds obvious, but there are companies that talk about it, and there are companies that actually internalize this and execute.  This is why Apple is so dominant.  It’s not the technology—the iPhone doesn’t have dominant specs; take screen size, camera quality, or network speed, for example.  But it does have a tightly-integrated value chain that creates such a great total customer experience (i.e., Apple store, iTunes, devices, highly-motivated application developers, etc.); it’s extremely hard for Google, Microsoft, and others to compete.

Look at Amazon v Barnes & Noble (here’s a link a relevant G+ post by yours truly: Hey Barnes & Noble, it’s not the Nook, it’s about Customer Intimacy).  Amazon is all about convenience and customer intimacy.  Amazon has made it amazingly easy to buy anything, not just books.  Electronic content with Amazon is very convenient—I read my eBooks from Amazon on my Kindle, iPad, Windows laptop, MacBook Pro, and my Android phone (which I will switch out for an iPhone when my wireless plan renews).  Amazon has created an amazing total customer experience, supported by excellent technology and business model innovations.

I like Square’s focus on small business.  Rabois’s response to the question about moving up-market is encouraging.  So many companies want to move up-market because deal sizes are larger and I believe partially because of vanity.  I agree with Rabois that Square has an immense value proposition (in a word, Simplicity) which is probably the #1 priority of buyers in most small business owners.  Medium or large-sized businesses would likely have a different list of priorities (e.g., deeper analytics), causing their “simplicity play” to be less effective.

I chuckled a little bit at the PayPal reference in the article because of experiences my wife has had in her adventures as an eBay vendor.  PayPal can be a pain to deal with at times, especially when your funds are on hold and you don’t know why.  Simplicity and transparency are paramount.

Thank you for reading!

If you’ve been following along, thank you!  This is my fifth post, which marks some sort of a milestone (or at least WordPress thinks so).  I am definitely open to having conversations, so please comment if you like the post, or better yet if you think I’m dead wrong!

You can find me on Twitter: @jimargarcia (Apparently there’s another Jimar out there that jumps on the “jimar” handle before I can.)