Is your Org Chart Broken?

Is your Organization Chart getting in the way of creating great products that delight your customers? Is it getting in the way of capturing more marketshare?  Let’s face it, the basic structure of org charts has not changed. There’s the President along with Vice Presidents heading up the Finance, Marketing, R&D and Sales departments. But why are many companies so dysfunctional when it comes to defining, building and delivering products? Maybe it’s the structure of the organization. We’ve seen it / lived it over and over – marketing and R&D sometimes just do not play nicely together. Fiefdoms, egos, mistrust – whatever the reason, it can be a real toxic atmosphere. And when times are tough (as they are now) the departments hunker down protecting their turf. And Product Managers who straddle both sides bear the brunt of all this as they try to get products and releases out the door. It’s no wonder that defining, building and delivering products and releases can be sometimes so hard. But it doesn’t have to be.

If you are in a product-driven company – i.e. the business model for generating revenue is by defining, building and selling products – or transitioning into a product-driven company, then this blog post is for you. If you are a services-driven company and have no intentions of becoming a product-driven company, then maybe this post is not for you.

Generally speaking there are 3 major buckets of activities within a product-driven company. Finance and Corporate Services look after the internal workings of the company – making sure that everything is in place and operating properly (including adhering to GAAP so that the president stays out of jail, but I digress).  Next is Sales and Services (if Services is a component of your product offering) who are responsible for extracting as much money out of new and existing customers as possible; whether it is direct, indirect, online, telesales, etc. And last (but not least) are the activities around finding markets, defining and building solutions to address market needs and supporting customers. The latter certainly sounds like Product Management. So why do we split this between Marketing and R&D? Why do we have separate fiefdoms to support this essential set of activities? Isn’t managing the product portfolio one of the most important activities in a product-driven company?

So we need to view the org chart from that perspective. I propose an org chart that views the activities of defining, building and delivering products as paramount.

As you can see I propose keeping the VP Finance and Corporate Services and VP Sales and Services roles intact. However the  Marketing and R&D roles become the VP Product Management role. This group is chartered with finding markets and their problems, defining solutions to address those problems, building the product, launching the product, communicating its goodness and supporting the customer base. As you can see everything related to the product is in one group. You’ll notice that product development reports into Product Management and that the Technical Product Manager role is absent – it’s part of Product Development. Lastly we have the CTO role. This role is about future technology – embracing new technologies, searching for / inventing technology that will improve the product in the future.

The biggest benefit? The management of the product portfolio, which is the lifeline of a product-driven company, is now the priority … not marketing it, not building it.

Clearly Define your Product Manager Role!

As software product companies adopt agile principles, the role of the Product Manager is changing and therefore needs to be clearly defined and established. As more and more companies adopt agile principles, people aspiring to be Product Managers need to understand what’s in store for them over the next 5 – 10 years. Looking back over the past 5 – 10 years the greatest influencer on developing products is the increase in the amount of change. It used to be that Waterfall methodologies actually worked well. Why? The reason is that once all the up-front requirements gathering and design was completed the amount of change over the course of the implementation phase was negligible. Projects that lasted a year and delivered product that was still relevant, were quite common.

Times are different, we as consumers love choices; we love changing our minds; we love new and innovative products. Even users of B2B products see what’s happening with the technology in our private lives – for example, searching for information on the Web where variations in search terms are easily handled and returns the highest relevant item has become standard – so why can’t my B2B product have the same capabilities? This all ripples up to the developer of the product. Bottom-line is that the ability to embrace change is key to surviving … and with the amount of change increasing, this is becoming quite a challenge.

So the trend of switching from Waterfall methodologies to Agile methodologies as a way of embracing change continues. More and more software product companies (and hardware product companies with a software component to them) are adopting, to some degree, an Agile methodology (Scrum, XP, etc.) to help them gracefully embrace the change that will inevitably happen. How this happens is that the amount of up-front activity is reduced to the bare minimum (as compared to the Waterfall methodology) – essentially what’s required to support the first sprint/iteration is completed up-front. The consequence, however, is that the up-front work for each feature/enhancement takes place when needed during the project – more of a Kanban (pull) approach.

Agile methodologies (Scrum in particular) introduces the role of Product Owner. There is much debate as to whether this new role is in fact the Product Manager or what activities the Product Manager now performs. The Product Manager role is very broad – it encompasses strategic activities related to the current and future target markets, technical activities related to the actual product and communications/training/support activities related to launch and sales. The technical activities of the Product Manager role are very closely aligned with the activities of the Product Owner. In smaller companies these roles can be supported by a single person and as the company grows multiple people will be needed; split between Technical Product Manager and Product Owner where they work very closely together. Companies that already have an established Technical Product Manager role are in a good position to make this transition. The key is that this role must extend from the customer/users to the development team – user intimacy, feature prioritization, requirements definition and prioritization, customer validation, etc. are all part of the role. Technical Product Managers that are too deep into requirements and design need to “move” towards the users – i.e. they need to be more engaged with the users of the product.

Companies that do not have the role of Product Managers crisply defined, will struggle in their transition. Product Managers that do (or attempt to do) all of the activities encompassed by all segments of the role will not be able to properly embrace the cadence and needs of the Agile methodology. In other words, the ability to provide the up-front work at a just-in-time pace during the project will be severely hampered. Companies need to clearly define this “customer/user to development” role and staff it properly. Responding to change throughout the entire project is vital … customer feedback comes quickly, business objectives/situations change – all of which needs to be handled very quickly and in time so that development is always busy and working on the most important items.

So the bottom-line is that product companies need to staff a role – Technical Product Manager – that spans the length between the users and the development team. Whether this role is the same as the Product Owner, depends on the size of the company. Companies also need to staff a role – Marketing Product Manager – that looks for and understands the markets that are suitable for the company to embrace. For start-up companies that only have the resources to staff one position – staff the Technical Product Manager role (as defined above) first – understanding your users and building your product that delights them will pay huge dividends in the long run.

Business-Driven Product Management – The Podcast

Last week, Michael Ray Hopkin from the Product Management Pulse interviewed me on the topic of Business-Driven Product Management. The podcast is now posted on his site: http://www.productmanagementpulse.com/business-driven-product-management.