Product Strategy: Conversions for Features II

In Product Strategy: Conversions for Features, I wrote about how the use of a control is equivalent to a conversion on a website. SaaS converts functionality into a collection of conversions. That article was abstract. In this article, I'll cover the same ground in a different way and arrive somewhere slightly different.

I'll start with a Twitter settings page.

I've annotated the contents of the Notices settings tab and form to highlight the components of the fulfillment chain. The offer is green. The conversion text is blue. The controls are red. The fulfillment that consists of an offer, conversion text, and a control or link is black. Even desktop-application GUIs have these components, but it's only in SaaS applications that these conversions can be tracked.

A more abstract representation can be drawn of the UI.

 I came across this system diagramming standard a long time ago, so I'm at a loss as to its name. I've extended it using the color code from the first figure. The underlying task starts at the left when the user clicks on the Notices tab. Then, the Notices form is displayed. The thick arrow transfers control from the Notices tab to the Notices form. Then, the user optionally clicks or selects the appropriate settings for each control. The task ends on the right when the user clicks the Save button. Between the start and end of the task, the settings can be set as many times as needed. The Notices form continues to be displayed until some other tab or link causes another page or form to be displayed. Settings can be abandoned just like shopping carts on an ecommerce site.

In this figure, I've given each control a histogram indicating the number of times each control was used. The brown sections of the histogram indicate abandonments.

Task 1 set the @Replies and Direct Email settings, and then exited. Task 2 displayed the Picture form, so its settings could be changed. Task 3 enable the receipt of auto nudges. The Notices form continued to be displayed after Save was clicked. Task 4 did not have to display the Notices form, and changed the @ Replies settting.

Since the settings were saved on the server, some server log activity resulted. Analyizing the server log can show you were interface problems are occurring.

The next figure shows how feature frequencies (blue), tool task frequencies (brown), and user task frequencies (red) are related.

Notice that just left of center is a task called Abandon. It is a task that was implicit in the user interface. The tool tasks (brown) are just rephrasings of the control label. Each feature has a corresponding tool task. They describe what each control enables at the level of the software. The user task (red) are higher level tasks that are performed as a sequence of tool tasks. The user task does not have to use or include every tool task.

Histograms illustrate some attribute of one or more population. Data warehouses aggregate data over time. Those aggregates result in stacked histograms. If our application supports several different user roles, then the frequency of use of a given feature would be distributed over those roles and the histogram could be an aggregate of each populations use frequencies.

This figure is representative of enterprise applications, which typically involve numerous roles. The application has features that are used jointly and others that are used exclusively be users working in specific contexts.

The producers might be from a single functional unit, or the application might be one of those integration applications. In the latter case, the producers could be further disaggregated. In the former, in a single functional unit, the producers could still be further disaggregated by differences in their approaches to work, or in other words differences in their paradigms, or subcultures of their discipline-originating culture.

In this figure, I've disaggregated the producers by their paradigms. On the left, I'm using Poisson distributions as indicators of the various populations. This representation of populations came from Myerson’s notion of a game with unknown populations. These games provide a good way of looking at technology adoption or the markets that you have sold and will sell your software into. This correlates with the use of different fulfillment chains or marcom document sets that target these different populations, and the user's post-sale enactment chain embedded in the actual use of the software and the user's interactions with technical support, training, customer support, accounts receivables, professional services and any other in offer business units. Each of these populations have a rate, which implies that a differential game exists as well. Such a game would describe the rate at which your prospects close or move across your marcom fulfillment chain and your sales funnel.

On the right, the producer portion of the histogram is broken out into paradigmatic populations. This disaggregation demonstrates a need to deaverage functionality. The histogram on the right shows producers who do cost accounting. Some will do traditional cost accounting, some activity-based cost accounting, and others still do throughput accounting based on the Theory of Constraints.

I noticed that the Twitter task was bookended by the Notices tab, and the Save button. I tried to graph the task over time, but since the form remained open, any number of subtasks could be performed, but a firm count of the task frequencies could still be determined by the number of saves made.

Taking those bookends as a header and trailer pair, let me visualize the Notices tasks as a packet, like an IP packet, and even go so far as thinking about an OSI analog to the packetizing process. Skipping that, we end up with a packet containing a number of bits related to the number of controls on the form. That an application is implemented as a GUI-driven application doesn't mean that it couldn't be a set of commands typed on a command line. That the view of the interface could be changed, means that you could those bits represent the model component of a model-view-controller.

This figure shows how task performance over time could be sliced up into a time series typical of data warehouse data, and how such data would be aggregated into a packet.

Once in packet form, we can look for interrupting tasks and abandoned tasks. Web analytics finds these things. I can't say how, but here is one possibility.

Using web analytics, user issues can be found in data derived from actual use. This approach can be used in prototyping situations as well. With user registration, you can disaggregate based on what you know about your users. You could disaggregate on functional culture, paradigms, or any other drivers of use and the meaning surrounding that use.

Leave a comment. Thanks.