This is the pattern for storytelling from the most effective presenters. Nancy Duarte mapped out the pattern of speeches that did a good job delivering a convincing argument for an idea.
Ted Talk: The secret structure of great talks
HBR article: Structure Your Presentation Like a Story
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.
We are designing the information displays for portfolio managers. In the process of understanding what information is needed we have identified from our resident portfolio managers and customers the need to get a quick overall status of the portfolios under management.
If we are looking at one portfolio there are some specific characteristics we would like to roll up and summarize. Let’s take the example in the fixed income world. If we have a portfolio of 100 securities, when we look at that portfolio summary we would like to get a sense of the spread, duration, convexity, and credit quality. When asked how they would roll this data up, the portfolio managers tell us to use a weighted average.
The problem is that the distribution of the data is non-normal most of the time so taking an average is useless. What would you do to express the overall distribution in non-normal data?
– create a plot – it is non-normal and the distribution is irregular so perhaps a distribution plot would be useful (a little sparkline of the distribution to give a general idea)
– monitor control boundaries – upper and lower bounds with counts below, in the middle and above would be helpful (this would allow the user to see the outliers quickly)
– measure drift – positive and negative drift from a benchmark or model where you want to be at for each position and identify the drift (this may be normal but I am not sure)
It seems to me that we could come up with many much more useful and truthful representation of the underlying data than the weighted average.
Have you played around with this?
Is there an industry standard for expressing this data?
Do you have some ideas?