Product Strategist: Projects Become Processes

As software vendors, we build products and we ship them. We don't have the same view of software development as the programmers in an IT shop. The in-house programmer lives in the same buildings as their users. The applications they develop and maintain turn into processes right there in the same building. They may never see those processes, but they are at least physically close to them, and have their development efforts driven by those processes.

As software vendors, we compete on features. After the sale and the installation if field engineers are needed, all we hear is from technical support, marketing research, and the feedback channels that product managers develop and maintain. We hope that we capture customer needs, but our solutions are always features. How far from the work, from the report users, from the process, from the management of that process is your product?

In http://www.noozit.com/article/.ee84c69, I expanded the triangle model, a model I use to provide an overview of the decision spectrum relative to a software application, or any other product. In that article I expanded the model to fit a browser-based client and served functionality. Previously, I had never considered operations, but I've worked in a hands-on SaaS shop, so operations and the daily marketing operations were just a few desks away. So the model needed to be expanded.

In this article, I'm going to break it into project and process, development and operations. I'm doing this to expose elements that provide competitive advantage beyond those fleeting features copied by the fast followers. These considerations reach beyond the triangle model and reach far into the vendor organization, particularly in a value-based vendor where even billing and shipping are part of the offer.

I know it looks like the waterfall. It could be. Or, it could be Agile. The diagram is really about decisions, as it is one big decision tree. Regardless, it is not likely that your entire company runs on Agile methods.

On the left, the project creates the functionality and documentation. In the center, user communications bridges the gap between project and process with information. On the right, the process emerges and lives, we hope, a very long and productive life.

The requirements elicitor, probably the product manager, according to research on requirements elicitation, has a theory (ET). If the company is in the SaaS market, then SaaS is automatically going to be part of the solution. technically, SaaS is not a what, but a how. It shouldn't get written into the requirements as a what. It's contractual like architecture, so it gets built. Where the elicitor's theory turns up is in the questions they ask as they elicit the requirements. It's a bias. And, the research showed that the bias is there. It is deep. If you've built average functionality to fit the aggregate user base that market segmentation created for you, that market segmentation is biasing, so it is part of the elicitor's theory.

We take the product of requirements elicitation, the requirements (R), into the design decisions, phase or not, and balance them against the impedances or constraints from the implementation environment. You could compete on implementation environment. We do even if we don't do so consciously.

Then, we move the design into the implementation (I) decisions and cycle as needed. We iterate. We get feedback. We iterate again. We test the delivered functionality in our server environment, but operations (Ops) might install it across a more robust environment that they manage. Does it scale up? Iterate. And, we test it on the browsers we are going to support in the customer's environment where the user interface is ultimately delivered. We might deliver APIs as well, another interface.

Those features are used at the level of the interface in terms of tasks. Some of tasks are tool tasks (TT). Others are user tasks (UT). User tasks are closer to the work the user does. We deliver the tool tasks and user tasks in the documentation, training and technical support that constitutes the non-marketing components of user communications (UC).

Then, the installs go to service delivery (SD), or operations (OPs). The user interface and client-side functionality is served to the browsers along with documentation, and desktop training, or not depending.

Then, it falls to the system administrators and users to do work design (WD), which does for them what design does for development, take the constraints of the interface and the requirements of the work and balances them. They have to implement work processes and deliver that as well. I've omitted that. Then, some days after their installs, downloads, or, more immediately, the page views, they begin to do productive work (W). They learn more. The refactor their work architecture and processes on the fly. They use their six sigma.

The report users don't show up in the diagram, but they are there as well with their reporting needs (requirements), report design, report related processes, and further upstream reporting to people who don't know here the data came from, but rely on it in some distant economically indifferent manner.

And, work processes require management, so you have management design (MD) and management (M) going on.

So what would you need to provide to facilitate work design? How can you make your application disappear in the flow of getting work done and staying focused on work, as users do? How can you facilitate report process design. How can you facilitate management design? Do you understand the breadth of metrics that might be needed to manage the process? Would a fast follower know all these things? Would an economic buyer know any of this? Who are you going to call to find out?

There are plenty of opportunities to create features across these layers of use, and to create them in a manner that will retain their differentiation and price premium in the face of the fast followers.

Comments? Thanks.