Should the product manager or user experience designer own and drive the product?
I have been working in the enterprise software industry for almost 18 years. The companies I have worked for have been successful and profitable for many years. In the beginning they started as engineering driven organizations and then, over time, they added product managers. While their world was competing on the features needed they were able to march forward with success. As all their competitors acquired the same set of features the current and potential customers started to recognize that complexity of use, cost of training and ability to meet their users’ workflows were increasingly important.
What should a successful software product company do about this problem? Switch the roles of who is leading to the team to put the emphasis on the workflows, tasks and users’ needs instead of the features. Here is the experience I have had with the team lead as product manager versus user experience designer.
User Experience Designer
|Every company I have been at has senior product managers running projects within a module of the application. The senior product manager does a lot of the project management and interfacing with the engineering team. The product manager talks with customers about issues, collects information from sales and service and therefore sees the product from a feature gap basis.||Instead of hiring senior product managers and more junior interaction designers at a module level, why not switch it around? Have a senior UX designer and a junior product manager. The UX designer focuses on the workflows and tasks of the user. The product manager focuses on the features and project management issues. Their basic roles do not change. The ownership and driving factors change.|
|As the product grows, complexity creeps in and users start to complain, a user experience designer is brought in to help. The interaction designer gets spread across many teams and is responsible for creating UIs for the product manager’s stories and to ensure the development teams are following those designs.||As the product grows, shifting to have the UX designer lead the module with assistance from the product manager, changes the the team’s perspective. This focuses the team on meeting the workflows, tasks and user’s needs as the primary focus. Problems are solved in a different way. The focus changes from the feature that needs to be created to the flow and layout through-out the application.|
|I have not seen the process of driving UI designs from a feature gap perspective succeed in any of the organizations I have been in. Designs improve marginally with some oversight. However, the designs are still within the construct of the latest features that needed to be added to the product.||This process has been successful for me working with product managers when I worked on the workflow problems across the modules and they were able to reorient themselves to this approach. When they could not change, the product continued to be built as one offs for the latest customer who had sway. It is clear that a change in focus would bring a greater deal of success meeting the customer’s needs. It is difficult to change when what you are doing was successful in the past.|
|The focus on features and the recency of the last customer complaints create a focus on minimal viable feature approach. The product manager figures out what feature is needed. He determines what can be done quickly to satisfice the customer’s business need. This translates to a development approach that looks to add the features with minimal impact to the existing code to avoid refactoring and extensive testing. Minimal viable feature sacrifices the long term maintainability and code reuse for the near term – just get it out the door.||The focus on workflows, tasks and user needs changes the perspective to consider cross-module issues and external influences on the use of the product. This approach facilitates simplifying and reusing similar components and UIs in the suite. Reuse and simplification from the user’s perspective translates directly to code that the developers are trying maintain and keep testable.|
Although this may be a subtle distinction for many and questions will be asked on why the product manager can’t learn to do such things, the stubbornness of human behavior has consistently demonstrated that changing the behavior of a successful product manager is unlikely. So why not re-conceptualize how product teams are led? Keep the same roles but change the emphasis on which role drives the decision making.