Product and the 4 Ps

Today I had a very interesting discussion with a colleague about a new product we are considering building. In the middle of this discussion, I had a great brainstorm. Since it relates to the 4 Ps, a common blog topic for me here, I wanted to expand upon it a bit further.

Software engineers tend to see a product in terms of the innermost "P". No surprise that this is the one called "Product". It relates to the technical specifications of the product itself, what is the composition, architecture, frameworks, development language, etc. This is the perspective that often measures the architectural purity of the software itself. It is concerned with the implications of various decisions on things like ability to scale or preservation of options for further ease of development. As engineers think about a product, this is a common perspective, and it often reflects their unique form of engagement with the software itself. If you have found yourself sharing this perspective, then you can recognize your connection to the Product or inner most level of the software.

However, there are other dimensions that relate to the product. The next one is Process. I think of process as relating to the different ways that the product is implemented. Does it require human intervention? Does it auto-install? In the case of enterprise software, it is very different than consumer software. Can it be deployed through an SMS tool such as LanDesk? Or does it require someone to physically touch every machine. Enterprise deployments often prefer to prevent the end users from touching the software at installation, therefore the process is very important. From a software engineering perspective, this often feels unnatural. Implementation represents the part of the Product definition that cannot be controlled. It is something that is very uncomfortable for a developer who is accustomed to working in a very controlled lab environment. But from my experience, this is a very important part or aspect of a Product.

The third level of product is the People level. Who are the people who will deploy/support/use the software? What motivates them to want to do this? Over the last few months I've become involved with clients and how they engage with the software. It is a very different what they see/do/think than what I as the developer think. It might be viewed as "yet another piece of software to be supported with the same resources." Or it could be "a tool which enables value and productivity." These are two completely different perspectives that result in very different approaches to promoting the software product. They are very important, and as the product is developed the features which contribute to the people's motivations to adopt and support it. Again, this is a realm that the developer cannot directly influence or control. But one which I think has a significant impact on the success of the product in the field.

The final level is Politics. What are the stances or commitments that the client organization has made. Do they want to brute force the installation? or do they want to use a deployment tool. Do they let their users have Admin privileges, or do they have to use tools to effect the deployment? What is the general priority of this tool versus all the other things that could command their attention. Who sets the tone or motivation for the team? All of these relate to the Politics side of the implementation.

One person often has a difficult time holding all these perspectives together. My experience says that one given person can hold only one or two of these viewpoints at one time. I think that using this framework outlines a lot of the development effort that needs to be accomplished to ensure success. I think that it is an area that requires a lot forethought about how to create value.

Stay tuned for my book about this topic. I've been thinking it through a lot in preparation for writing soon.

Every day my job brings me a wealth of observations about life in a technology company. Whether by observing office politics or by translating my hobbies, I gain insights into what works and what doesn't. My goal is to share these insights (protecting the guilty and innocent alike) to encourage you to engage deeply in your passions for greatness in your own life and career.

Disclaimer: Blog contents express the viewpoints of their independent authors and
are not reviewed for correctness or accuracy by
Toolbox for IT. Any opinions, comments, solutions or other commentary
expressed by blog authors are not endorsed or recommended by
Toolbox for IT
or any vendor. If you feel a blog entry is inappropriate,
click here to notify
Toolbox for IT.