Product Strategist: Product Shaped Hole

A few days ago, I read a post "The product owner and the product-shaped hole" on AgileProductDesign.com, see http://www.agileproductdesign.com/blog/2009/product_owner_and_problem_shaped_hole.html. So I've wanted to post on this topic. A comment wouldn't have been visual enough to address how we can define and shape the hole. From there, keeping the team up to date on changes to the shape of the whole should follow naturally.

We can create a visual representation of a gap.

You end up with two different scales facing each other. Each measuring their position from the perspective of their own organization. Each measured to a scale appopriate to each organizations capabilities. A is linear. B become logrithmic. B has some secret sauce for the moment. The scales show both the internal and external perceptions of performance relative to the compared attribute. Such attributes could be feature performance, or how nice customer support comes across, or how aggrevating accounts payable can be if the customer happens to be a low payor. For our hole, we will measure offer attributes across the corporation. You offer mix may vary.

Any object has a collection of attributes. Each attribute has its own data type which implies a scale and a unit measure. Each attribute has its own axis where the value is plotted.

The direction of these axes is arbitrary. You can product this kind of graphical representation in Excel.

You can show your intentions towards a goal relative to the collection of attributes that contribute to that goal using this representation.

The gray vectors represent the intended goal. For 1, the goal is distant. Progress towards the goal could be indicated by marking the iterations or releases towards it, so that the graph along the axis would reflect the rate of progress. For 2, we have delivered well beyond the goal. This is problematic where it represents the over-served customer, one of Christensen's indicators of where an attacker should strike an incumbant. It is not problematic if it represents a buffer in terms of scalability, particularly on the IT ops side of SaaS service delivery. For 3, the goal is near, and much effort has been expended. This might be the case where the technology is at the top of the S-curve where costs are the limiting factor and the performance upside small.

On this figure, we can see some variations what can be represented. Notice a vector or axis that is only a goal for now, and another that changes direction. Such a change in direction would be necessitated by entry into the late market, commodification, or just a compettive response to fast followers, particularly if the underlying model is not exposed in the interface, as it leaves the follows wondering.

You can show your competitive situation along these axes as well.

Here each axis represents each party proportionally. They could be an aggregate of all of your competitors, or just one competitor. The point of the hole is clear communications with your Agile developers. These proportions could be updated as frequently as your competitive intelligence and win/loss analysis allows.

When you are better than your competitor, you have a positive point of difference (+PoD). When your competitor is better than you, you have a negative point of difference (-PoD), or you might consider them to be a point of contention (PoC). You have to decide whether further investment in a point of contention is going to deliver a reasonable return. If both you and your competitor are approximately similar, then you have a point of parity (PoP). Another point of contention occurs when you have no competitor along a particular axis. I use a proportional representation to eliminate the problem of different scales. The idea was to have you and your competitor face off, force against force.

Similarly, you can map your value chain participants in the same manner.

In this figure, you have noticed that a competitor, the tracking competitor, that has competed with you in the past stopped doing so. You also know that a supplier has promised with FUD to deliver a technology that would enable you to move towards one of your goals. Announcements seem to indicate that you can ride their performance improvements for a few release cycles. You are also mapping a complementor. You see that that complementor has not progressed since the last release. Someone in support or professional services might want to contact them to get them moving again. You might even plot open software efforts at sublimating your complementor, as losing complementors is not good for your business.

In this figure we map our positions relative to each of our competitors along all our attribute axes. You might want to draw each of the competitors from the object out, but clarity would demand that for a given attribute, the relevant competitors would be adjacent to each other. The attribute postions should not be considered fixed. In the case of fluid axes, you would have to label the axis. You could make them hiearchical as well. Notice that the attribute on the bottom left includes a complementor axis. Complementors add functionality to a given feature or collection of features. Absorbing complementor functionality adds to your cost structure. It also narrows the appeal of the functionaliity, and the relevant messaging. Your complementors helped you grow. Help them live long and fruitful lives. A company cannot make a market alone.

You might also graph your whole product partners as if they were complementors.

With followers, it is good to know when they started following you, or if you actually followed them for a while.

On the top axis you entered the competition along this axis after they created the axis. On the bottom axis, they entered an axis you were competing on. Their progress has been slow. Somthing enabled them to enter the axis without the learning that you captured prior to their entry. Has that earlier learning been commoditized by a lightweight protocol, or documented well, or sublimated by another vendor that you are not paying attention to?

In some sense, every requirement is an attribute that can be tracked relative to the released product. The requirements would be tracked over the entire life of the product. By positioning the requirements around a circle, you can account for their hiearchical nature, and their fluxuating density.

Each circle represents a release. Requirement 2.1.0 is hierarchical. The requirements push out against the customer performance and preference rankings, or competitor performance, not shown in this figure.

Here the hole being filled is shaded.

In terms of defining the hole, you could use business rules technology to define the organizations goals and means. As a decision tree, you would end up with something like this triangle model, you are shaping a surface. You could then change the representation, so the resulting surface encicles a space.

On this figure we show the organization as the definer of its IT Ops, Sales, Dev, Mkt and other capabilities. Each capability is a branch of the decision tree. IT Ops is not the owner of dev, nor sales of marketing. Notice that the organization does provides some of the offer elements like billing and license management. The role of sales in this organization is limited to the acquisition of new customers, as subseqent upgrades or subscriptions are habitual and done either online or through an inbound call center staffed with farmer sales reps. The yellow space is that of tool tasks, user tasks, scenarios, work design, work, management design and management. The yellow areas are part of the user's/manager's/economic buyer's goal spaces that end up encoded into the requirements of the product filling the hole (black).

Business rules technology encodes policy or other decisions. As those decisions change, visualizations could highlight where code and policy conflict.

Thanks to Jeff Patton for seeing the product as filling a hole.

Comments? Thanks.