Holistic View of Product
For a startup, where there’s typically just one product team, it’s not too hard for the leaders to keep in their heads a holistic view of the product. However, this quickly becomes much tougher as the company grows first to a larger product and soon to multiple product teams. One of the challenges of growth is knowing how the whole product hangs together.
There are actually three distinct but critical elements to the holistic view:
- Principal Designer (or Leader of User Experience)
To me one of the most important roles in a company is the person responsible for the holistic user experience. This person must ensure a consistent and effective user experience system-wide. This person is sometimes the leader of the user experience team, and sometimes a principle designer reporting to this leader. It is usually an interaction designer or information architect by training. Ensuring a consistent visual design is also important but there are mechanisms to do that, such as style guides which we encode in style sheets and templates. The real difficulty is in ensuring a consistent and effective interaction model across the breadth and depth of the user experience.
There are so many interactions and inter-dependencies, and so much necessary institutional knowledge of the business and the users, that you need to have at least one person that is reviewing everything being proposed for the site that is going to be visible to the user. You can’t expect any individual product manager or designer to be able to have this all in their heads.
- Principal Product Manager (or Leader of Product Management)
In order to ensure a holistic view of how the entire system fits together from a business point of view (product strategy, functionality, business rules and business logic) we similarly need either the leader of the product management organization, or a principal product manager. For large organizations I prefer this to be an individual contributor role (principal product manager) but let me be clear that this is a very senior role (usually equivalent to a director level manager). The problem with also being a manager is that this person needs to be focused on the product itself and readily accessible as a critical resource to all the product managers, user experience designers, developers and QA. This person should be reviewing the ideas and plans of the various product managers.
This is a critically essential role for companies with large and complex business systems, especially with many legacy systems. If this is an individual contributor, he or she should be a direct report to the head of product so that everyone understands the importance of the role and the responsibilities of that person.
- Software Architect (or Leader of Technology Organization)
Finally, in order to ensure a holistic view of how the entire system fits together from a technology point of view, we have the role of software architect. This person is responsible for the holistic view of the system implementation. This person should be reviewing the architecture and systems design of all the software, both systems developed by your own staff as well as any systems designed by vendors. Again, this is a critically essential role for companies with large and complex business systems, especially with many legacy systems, and should be placed in the organization somewhere that makes this person visible and available to the entire technology organization (this is usually a direct report to the head of technology).
I describe this architect role in more detail in this earlier article: http://www.svpg.com/the-architect-role/.
The larger the company gets the more critical these three roles are, and the absence of these roles is usually all too obvious. If the site looks like it was created by half a dozen different outside design agencies, with conflicting user models and poor usability, you’re probably missing a principle designer.
If projects are constantly getting stuck because product managers don’t understand the implications of their decisions or product managers are constantly asking developers to look at the code to tell them how the system really works, then you’re probably missing a principle product manager.
And if your software is a big mess of spaghetti and it takes forever to make even simple changes, you’re probably missing a software architect.
You might ask what happens if one of these people gets hit by a bus or leaves the company? First and foremost, don’t lose these people! Take care of them and by all means don’t give them any reason to want to leave or feel like they need to become a manager to make more money.
Second, you should always be trying to breed more of these people, and each of them should have at least one person they’re working to develop into a strong second. But they are always rare as this learning does not happen overnight and these people are incredibly valuable.
Some companies think the answer to this is to try to document the system to the degree that this is all captured somehow in a way that members of the organization can all go to for the same sorts of answers they use the principle designer, principle product manager and software architect. This is actually the subject of a future article but I will say here that I know several organizations that have tried hard to achieve this, but I have never actually seen this succeed. The systems always seems to grow in complexity and size much faster than anyone can document, and in truth with software, the definitive answer always lives in the source code itself (at least the current answer – not usually the rationale or the history).
If anyone knows of a situation for a significant sized software system or site that has managed to find a way to truly capture any of these three aspects of the holistic view, I’d love to hear from you.
One final note. These three people – the principal designer, principal product manager, and software architect – are obviously very valuable individually, but in combination you can see their real power. Any head of product with access to these people knows he can do some pretty amazing things.