How to Start to Solve the Problems of Your Product Development Organization

I have been thinking a bit about organizations and in particular, where I need to engage organizations to be most effective at helping them solve the problems of the overall business.

To better understand what has shaped my thinking I’d like to start with a bit of history around my background and life experiences. I initially started as a networking administrator within an old school ISP service organization and then my career progressed away from support services and into shared services and eventually product development. My experience in a variety of roles provided me with a set of perspectives around service and product development organizations.

These two key organizational types have distinctly different engagement models for me. If you have read some of my other work, I have a solid perspective on solving problems, and you’ll know that I don’t implement agile to be “more agile”. Agile is a large tool in my toolbox and tends to assist in solving a core set of issues that affects organizations: time to market, predictability, cost reductions, and quality to name a few. When I enter organizations, these two organization types are patterns that I look to identify to help me solve their problems.

A service organization is generally an enabler of a real business function like sales of human capital or, put in a nicer way, staffing. Thinking back to my history with a big player in the healthcare staffing space, IT was a function of the business not the business itself. We typically did things like CRM development and website development that facilitated lead generation and the like. The business makes a pull for a new service to be available to the real product Sales. In this type of organization, I find it useful to transform in IT unless I am encapsulating the entire value chain from initial contact to opportunities for converting and through to conversion of the sale and possibly beyond.

For that reason, the IT group is there to make the life of the sales organization more efficient, or restated, to enable more and higher sales and generate more money. IT is an enabler for sales. In these organizations, I am fine with an IT implementation of agile that gives lead times to the organizations and that can make reliable commitments to delivery. The overall goal is to enable generation of more leads and to close more sales buy providing services that enable the organization.  The goal would be to reduce cycle time through automation of processes.

The IT failure would be if they are the bottleneck in the cycle time or if they are elongating it.  Beginning with IT allows me to focus on a predictable delivery of capabilities to an organization with the goal of enabling the real customer of IT, sales. Sales in this case would be to both the businesses wanting a staff augmentation and the person that wants a job. They are split out in organizations depending on the size of the staffing company, but those are the two basic products.

I find product development organizations to be a little bit different and I’ll warn you, I don’t share the same sentiment others do. Product development organizations are fundamentally broken most of the time. I hear “the business” a lot… and in truth, I hear it in service organizations too. Nevertheless, “Us and them” is the prevailing attitude in sales, marketing, product, and IT in many organizations. In my experience, product and development are one and the same most of the time if you use the 80/20 rule. They share the same agenda. Get products to market that improves the bottom line while excelling in the market.

Sales heavy organizations will tend to favor contract fulfillment, market penetration, and customer retention.

Market based organizations will tend to favor consumer behaviors, finding new markets, and trends.

Either way, you develop product to help you fulfill those needs. In both cases, I foster or create the partnership between product and IT organizations. That’s one reason why I look to solve the problems of the CEO or VP of a division. The person sponsoring the change needs to be a part of the organization that can ensure the bond does not break.