As I watched Professor David Sumpter’s captivating Oxford Mathematics lecture, Four Ways of Thinking: Statistical, Interactive, Chaotic and Complex, I found myself reflecting on my journey as a product manager. Each of these thinking approaches resonated with my experiences, and intriguingly, I recognized the same pitfalls that Professor Sumpter eloquently outlined.

In this article, I aim to share my insights, drawing from real-world scenarios, and explore how these thinking paradigms intersect with product management. From statistical analysis to chaotic adaptability, each approach has shaped my strategies and influenced my team’s success. So, let’s delve into the fascinating world where mathematics meets product innovation!

The Misleading Mirage: Statistical Pitfalls in Product Decisions

Statistical thinking involves analyzing data to make informed decisions. It’s about identifying patterns, correlations, and probabilities. While statistical analysis is essential for understanding user behavior, is your data really telling you anything? I often used the phrase: “There are three kinds of lies: Lies, Damned Lies, and Statistics” (and I have been guilty many times of misattributing it to Mark Twain) and sadly I’ve seen the truth of it many times.

Drawing from my studies in research psychology, I learned to see beyond the raw data. When I step into managing an existing product, I make sure to remain unbiased and thoroughly verify the data our team uses for decision-making is defined in a way that could distinguish causation. It is crucial to differentiate between cause-and-effect relationships.

For instance, if your metrics said that only 10% of users were responding to a specific notification don’t immediately assumethe notification was bad, or that 90% of people don’t like notifications and will never respond. First check to see if the metrics show how many user saw the notification. Look to see if the team had tried using different triggers to send the notification, and whether there are other notifications to compare against (either within the product or from competitors).

In the above example if your metrics that show that only 50% of users saw the message making the response rate 20% does that make it a good message? If the message went out to all users, but only applied to 50% of the people who saw the message does that make it a good message? At this point the message is getting a 40% response rate of the users that it applies to. How does the calculation change if average notification response rate is usually 15%?

Avoid these two common pitfalls:

1. Overreliance on Averages: Suppose a product manager analyzes user engagement metrics and finds that the average session duration is 5 minutes. Based on this, they decide to optimize the app for longer sessions. However, this overlooks the distribution—some users might spend hours, while others leave within seconds. Focusing solely on averages can misguide product decisions.
2. Ignoring Outliers:Statistical thinking often ignores outliers. Imagine an AI-powered recommendation system that suggests products based on user history. If an outlier event (e.g., a one-time purchase) significantly impacts recommendations, users may receive irrelevant suggestions. Product managers must consider edge cases and outliers to avoid unintended consequences.

In short, while statistical analysis is crucial for understanding user behavior, it’s essential to recognize that data can sometimes be misleading. When managing a product be sure to verify data definitions to distinguish causation and avoid overreliance on averages.

Interactive Overload: Balancing Collaboration and Feature Creep

To move beyond simple statistical analysis, it is essential to consider interactions and build models that contextualize data in relation to other factors. Interactive thinking emphasizes collaboration, feedback, and adaptability. While it fosters creativity, it can also lead to challenges:

• Feature Creep:In an interactive environment, stakeholders’ ongoing input can challenge product managers in prioritizing features. For instance, adding different personas to an AI chatbot intended for customer queries may sound reasonable, but ultimately could diminish efficiency.
• Scope Creep: Interactive thinking fosters flexibility but risks blurring project boundaries. For instance, when improving an AI chatbot for customer support, additional features like social media integration and e-commerce capabilities may be introduced, potentially diluting focus and hindering efficient customer assistance.

When Triage Goes Awry: Unraveling the Web of Confused Priorities

One way product managers get interactive feedback is through reviewing bugs and feature requests, a crucial part of the product manager’s job. Let’s explore this in more detail.

Effective Triage involves assessing the severity of bugs and understanding the impact of feature requests. For bugs, prioritize those affecting a large user base. For features, utilize the User Impact Score (UIS)incorporating vote velocity and affected users.

Product managers typically prioritize tasks in agile processes, often through triage meetings with multiple stakeholders. Unfortunately, poorly run triage sessions can distract teams and lead to scope creep. For instance, at two large enterprises, daily or bi-weekly triage meetings with 5+ stakeholders were common. Despite starting with critical issues, systemic problems hindered efficiency:

• Wrong Prioritization: The default priority for new issues was “critical” and most often was never changed.
• Poorly documented: Often there were no steps to reproduce, or there was incomplete information on environmental or system requirements.
• Can not be reproduced:customer bugs were not validated, and automation bugs were not manually tested.
• Misassignments: Cross-functional teams lacked clarity on responsible teams.

These issues weren’t occasional errors but became systemic, leading to lengthy meetings where most issues were minor or dismissed, often ending before all issues were triaged due to time constraints. This loss of daily development time significantly impacted productivity, especially with two to three engineers typically present, often reluctant attendees. As product manager, I focused on improving communication, documentation, and issue prioritization. I maintained flexibility while reinforcing simple standards. Collaboration with sales and support was also crucial in effectively managing new feature requests.

Returning to the example of notifications, we faced the challenge of excessive notifications at one company, compounded by custom feature requests from key accounts. We had a large backlog and accommodate all the requests was not feasible, and justifying the importance or design of our notifications was not always straightforward.

To address this challenge, our team implemented interactive methods to create and monitor more relevant notifications. Instead of indiscriminately sending notifications, we incorporated triggers such as time, location, event, behavior, and threshold. A/B tests were conducted to streamline customization based on feedback, particularly from key accounts.

Furthermore, I recommend integrating personas and preferences into the process to respect individual user preferences and enhanced engagement. Unfortunately even after you have added triggers, personas, and preferences that data may still not be able to explain everything…

Chaos Unleashed: The Perils of Reactive Decision-Making

Chaos is a common challenge in product management, but the key is how we manage it.

Chaotic thinking, while promoting agility, can also precipitate reactive decision-making and the neglect of governance processes, posing significant risks to product stability and user trust.

For example, within a chaotic environment, product managers may impulsively adjust parameters in response to immediate crises, such as when an AI model generates biased results. This reactive approach can compromise both product stability and user trust over time. Additionally, chaotic thinking often sidelines critical governance processes, particularly in the development of AI-driven features. Product managers must prioritize establishing guidelines for ethical AI, bias mitigation, and model monitoring to mitigate the risk of unintended biases or legal ramifications.

Chaos in Motion: The Evolution of Features from Idea to Implementation

As a product manager, I’ve observed how features evolve, and too often devolve, from their initial request to the final implementation. The transformation becomes more evident the longer the journey. Sumpter’s lecture aptly highlights a problem in the fourth decimal point. To illustrate this, consider the common journey of a feature request:

1. Customer Request: It all starts with a customer’s need or idea.
2. CRM Ticket: Formalizing the request into a Customer Relationship Management (CRM) ticket, capturing essential details.
3. Issue/Project Management Ticket: The ticket evolves further as it enters the project management phase. Here, teams break down tasks, assign responsibilities, and track progress.
4. Developed Feature: Finally, the feature takes shape through development efforts.

The challenge lies in maintaining alignment throughout this journey, ensuring that the end result reflects the initial intent. Unfortunately, it often does not.

Demonstrating Chaos With a Game of Telephone

While on one of my business trips to India I mentioned the Telephone game (aka Chinese Whispers) to my management team and discovered they were unfamiliar with the game. Fortunately, we had a team building event at the end of the week and I thought it would be fun to play Telephone as part of the activities. I gave the event coordinator the following simple instructions:

1. Players sit in a circle.
2. The first person whispers a message to the next person.
3. Each player continues whispering the message to the next until it reaches the last person.
4. The last person announces what they heard—the challenge is to see how accurately the message was passed along.

At the appointed time 30+ employees gathered in a circle to play. The first time around I was shocked that the message was correct! I quickly saw the problem: the message was too simple— that might work with children, but my team was way too good for that! I decided I needed to add a little more complexity and with that complexity the chaos began.

I think it will help to provide the two messages to illustrate how a little bit of complexity can have an effect, but I’m going to use variables so as not to embarrass my former company. Here is the first one:

{Our product} is the best {type of product} in the world.

The above came through 30 whispers without any change. I decided to add a user story, and picked one of our most compelling features. Here is the second one:

{Our product} is the best {type of product} in the world because as a {customer} I can use {capability} so that {received benefit}.

Even with the added user story the whole sentence was roughly 25 words. So, are you curious what the results yielded? Here is the result:

{Our product} is the worst {type of product}.

Honestly it was hard to hear the final answer. It felt like a gut punch, but I don’t think I could have asked for a better example— and we all enjoyed a good laugh after the initial shock. It was interesting to track back the message. It survived the first 10 players without much problem, after another 10 the whole user story was forgotten, and after another 5 “best” became “worst”. (LOL There was quite a pause between the last 4 players!)

All product managers should consider reviewing the original ticket or email request before releasing a feature. Additionally, it’s valuable to review the Product Requirement Document (PRD) or the definition of the Minimal Viable Product (MVP) before releasing a product. (Since the MVP definition warrants its own article, I’ll refrain from further discussion on it here.)

Shielding Against Chaos Thinking with Agile

In the dynamic world of product management, chaos is always lurking—whether it’s shifting priorities, unexpected challenges, or the ever-elusive “unknown unknowns.” The agile process acts as our shield against chaos thinking. Let’s explore how:

Agile Process: Taming the Chaos Beast

Agile isn’t just a buzzword; it’s a mindset. Here’s how it helps:

• Iterative Approach: Agile breaks down work into smaller chunks (sprints). Each sprint delivers tangible results. Chaos hates predictability, and agile thrives on it.
• Feedback Loops: Regular check-ins with stakeholders ensure alignment. Chaos thrives in isolation; feedback keeps it at bay.
• Adaptability: Agile embraces change. When chaos strikes (and it will), agile teams pivot swiftly. Think of it as controlled chaos.

2-Week Sprints: The Goldilocks Zone

I have not always used 2-week sprints, and I’m not going to tell you it is the right choice for every team, but let me explain why I think 2-week sprints hit the sweet spot most often:

• Parkinson’s Law: Work expands to fit the time allotted. With 2 weeks, teams focus on essentials. No room for fluff.
• Cadence: A rhythm emerges. Teams learn to complete tasks within the timeframe. Chaos hates predictability.
• Feedback Frequency: Twice a month, real client input shapes the product. Chaos trembles when faced with real-world feedback.

Remember, chaos isn’t the enemy; uncontrolled chaos is. Agile and 2-week sprints keep chaos in check.

Complex Thinking in Product Management: Balancing Ambition and Agility

As product managers, we’re the architects of innovation—dreamers who envision grand solutions while juggling the realities of tight timelines and ever-changing landscapes. Enter Complex Thinking—our secret weapon for thinking big while remaining agile.

Complex thinking encourages us to dream beyond the next sprint to create Visionary Roadmaps. When building a roadmap, consider your

• Macro Goals: Define your North Star—whether it’s revolutionizing customer support with AI or creating a seamless user experience.
• Emergent Strategies: Be open to unplanned actions and pivots while maintaining focus on the ultimate vision.

Maintain Adaptive Agilityin both sprint planning and your thinking:

• Scenario Planning: Anticipate different futures and be prepared to adapt accordingly.
• Feedback Loops: Embrace user feedback, iterate, and evolve continuously.

Complex thinking acknowledges interconnectedness and emergent behaviors.

Navigating Complexity: Pitfalls and Solutions in Product Management

While essential for all products, complex thinking also presents its own set of challenges:

• Unintended Feedback Loops:Consider an AI chatbot trained on user interactions. Complex thinking recognizes that user behavior influences the model, shaping subsequent user behavior. If the chatbot unintentionally promotes harmful content, it perpetuates negative feedback loops. Product managers must anticipate emergent behaviors and proactively intervene to mitigate risks.
• Model Interpretability:Complex AI models (e.g., deep neural networks) lack transparency. Product managers must strike a balance between accuracy with interpretability. If a chatbot makes a recommendation, users need to understand why. Complex thinking involves explaining model decisions, even if it sacrifices a bit of accuracy.

Complex thinking isn’t about solving differential equations; it’s about balancing ambition with adaptability. As product managers, we’re the conductors of this symphony—harmonizing statistical insights, interactive feedback, chaotic pivots, and the grand complexity of our product vision. So, embrace complexity, think big, dance gracefully on the tightrope of agility, and dream beyond the next sprint.

Summary of Thinking Pitfalls and How to Avoid Them

I wanted to end with a synopsis of the the thinking mistakes and solutions using some examples that are currently relevant to those of us working with AI.

1. Statistical Traps

• Mistake: Relying solely on averages. Imagine ChatGPT’s response rate is 20%. But what if it applies only to a subset of users?
• Solution: Contextualize. Compare against industry standards. Is it truly effective?

2. Interactive Overload

• Mistake: Over-collaboration. Too many cooks spoil the roadmap. Complex thinking balances collaboration with focused decision-making.
• Solution: Involve stakeholders strategically. Prioritize high-impact conversations.

3. Chaotic Whirlwind

• Mistake: Reacting impulsively. Imagine an AI glitch causes chaos. Complex thinking prepares you for crises.
• Solution: Contingency plans. Anticipate worst-case scenarios. Stay calm.

4. Complexity Paralysis

• Mistake: Overcomplicating. ChatGPT’s underlying algorithms are complex, but your roadmap shouldn’t be.
• Solution: Simplify. Break down features. Prioritize clarity over intricacy.

Conclusion

Product managers benefit from comprehending the four thinking approaches, guarding against their pitfalls, and leveraging their insights to enhance product development. Statistical insights guide decision-making, interactive collaboration fosters creativity, chaotic adaptability ensures agility, and complex understanding navigates complexities. By embracing these diverse perspectives, product managers can craft resilient, user-centric solutions, while sidestepping common obstacles.

As a seasoned product manager, I’ve encountered the intricate challenge of balancing feature development amidst diverse stakeholder demands and limited resources. Through navigating these challenges, I’ve refined my approach to craft roadmaps that resonate with sales, marketing, and development teams.

Central to this approach is the strategic categorization of features into four distinct buckets: Growth Drivers, Customer Feedback, User Experience (UX), and Internal Issues. Through this method, I’ve fostered transparency and accountability within product teams, prompting critical reflection on the rationale behind feature implementation. Join me as I delve into the art of crafting roadmaps that resonate with stakeholders and drive successful product releases.

Avoiding Critical Errors: The Danger of Overlooking Non-Urgent Yet Important Tasks

Managing tasks presents challenges, often exacerbated by stakeholder disagreements. Internal tasks, lacking direct customer requests, are commonly overlooked for their perceived lack of urgency and importance. Conversely, sales-driven requests tend to receive heightened urgency, despite their varying degrees of importance. Bugs, although crucial, often lack advocacy unless prompted by customer complaints or Support License Agreement (SLA) obligations. Neglecting non-urgent yet important tasks can result in critical errors.

In evaluating the significance of internal tasks, the Four Quadrants of Prioritization can be utilized, drawing from the principles outlined in the Stephen Covey’s 7 Habits of Highly Effective People. This framework emphasizes prioritizing tasks based on their urgency and importance.

Utilizing the Four Quadrants of Prioritization offers a structured approach to evaluating task significance. By adhering to this prioritization model, organizations can mitigate the risk of overlooking vital issues in favor of addressing seemingly urgent but less critical issues.

Inside the Buckets: Unveiling the Four Key Components of Success

Uncovering True Market Movers for Growth

Growth driver aim to enhance customer acquisition, retention, referrals, revenue, costs, satisfaction, loyalty, and competitive advantage. While only a select few features truly propel market momentum, customer requests received through sales channels are often positioned as such.

Traditionally, growth drivers are identified within a Market Requirement Doc (MRD), which outlines the essential features and functionalities of a product or service based on market needs, customer feedback, and competitive analysis. Serving as a blueprint for product development, the MRD directs the creation of solutions that address market demands and drive business success. Even without formal documentation, allocating additional time to market analysis is crucial in identifying potential growth drivers.

When evaluating requests from sales, it’s important to consider their broader market impact. While a feature may be significant to a single account, it’s essential to assess its potential for broader market appeal.

Furthermore, it’s imperative to assess the impact of new features on existing business dynamics—recognizing that not all growth is beneficial. Will new users complement the existing user base? While increased engagement is desirable, careful planning is essential to ensure that infrastructure, such as servers, can accommodate the additional volume.

Moreover, not all revenue opportunities are advantageous. Even if a customer is willing to pay a Non-Recurring Engineering (NRE) fee for a custom feature you need to consider the market value. The NRE development potentially divert existing resources and disrupt current commitments. Before proceeding with NRE calculations, it is crucial to evaluate their impact on the product roadmap and assess any potential effects on competitive standing.

Given that the product’s success hinges on improved metrics, garner support for market-moving initiatives from all stakeholders.

Prioritizing Customer Feedback for Impact

While it may seem straightforward, it’s crucial to heed your customers’ input. Customer Feedback can come in the form of feature requests and bug fixes. While implementing every suggestion may not be feasible, maintaining an open-minded approach is essential. A proficient product manager will know which features the customers are asking for the most.

At a minimum, document a user story for each feature request. I’ve found success by enlisting support to draft the initial user story, refining it as needed thereafter.

For products targeting businesses, incorporating a business case can be advantageous. While user stories focus on the product’s functionality from the user’s perspective, the business case identifies how the feature will benefit the customer / business. Sharing the user and business cases directly with development can also help clarify the request.

Always try to include some obvious customer requested features with each release. Excluding features actively advocated for by customers can be a source of frustration.

Additionally, addressing bugs is imperative. While customers appreciate new features, even minor bugs can be bothersome. While a bug fix may not directly impact sales or help marketing, leaving bugs unresolved can significantly frustrate customers. There is a reason why we call issues “bugs”- they bug people.

Unveiling the Art of Delightful User Experience Design

User Experience (UX) features encompass elements that, while not explicitly requested, evoke delight among customers upon encountering them.

Even with proactive outreach efforts, customers often provide limited insight into their preferences. Quantifying user feedback can be challenging, with the 1% Rule often cited as a reference point for social media engagement. This principle suggests that 90% of users are passive, 9% occasionally engage, and only 1% are heavy contributors. Similarly, online product reviews on platforms like Amazon typically involve around 10% of buyers leaving feedback. Given this scarcity of user feedback, improving UX typically requires progressive action to improve.

A quintessential UX challenge lies in user onboarding, as users who are dissatisfied with a product often refrain from providing feedback. Analytics are pivotal in revealing UX friction by pinpointing bottlenecks, unused features that should be removed, and to identify high use features and workflows that should be refined.

Two important metrics that can help with onboarding is retention and churn rates. The retention rate is the percentage of customers that stay with you. The Churn rate is the percentage of customers that leave within a given amount of time. Analyzing retention rates offers insights into churn rates and highlights the need for potential improvements in user onboarding. Additionally, examining metrics like Daily Active Users (DAU) can provide further context.

A proficient product manager goes beyond merely addressing customer feature requests or bug fixes, often finding innovative solutions in unexpected ways. Whether leveraging focus groups, analytics, or intuition, effective UX solutions integrate feedback from multiple users to craft innovative designs that address customer pain points.

Prioritizing Internal Features for Future Success

Internal issues are often essential but lack direct user demand leading them to be categorized as Not Urgent but important. Consequently, they risk being overlooked amidst more immediate concerns. Some examples of internal issues are: analytics integration, security updates, infrastructure upgrades, database optimization, code refactoring, and technical debtreduction.

An illustrative case highlighting the importance and complexity of prioritizing internal features can be observed in a SaaS enterprise solution that underwent significant growth. By its third year, challenges arose as the original codebase struggled to scale, the framework became outdated, and limitations surfaced within the database schema. Moreover, the absence of built-in load balancing posed immediate concerns, prompting makeshift solutions to alleviate server strain. Database schema issues led to difficulties processing reports, occasionally resulting in system freezes that impacted both the requesting customer and other tenants. To mitigate this, some reports were removed to prevent server overload. Additionally, demands for customer-requested reports, a key feature of the product, proved challenging due to a lack of common keys or suspected computing requirements.

The user interface (UI) presented another significant hurdle, with an outdated framework, numerous limitations, and impending end-of-support for the current version. Despite these challenges, some advocated for delaying addressing the technical debt in order to focus on sales related priorities.

Following a comprehensive assessment of the technical debt, the team opted for a full rewrite, initially estimating a six-month timeline with all available resources. However, this timeframe proved unrealistic due to competitive pressures, sales demands, and as SaaS product there were established SLAs that had to be met. Consequently, the roadmap was divided into two paths: one for ongoing maintenance of the original codebase and another for developing a new solution. Resources were allocated accordingly, with most new features prioritized for the new codebase and non-critical bugs deferred. Ultimately, the anticipated six-month project extended to 18 months to accommodate the complexities and demands of the transition.

The outcome was remarkable, as the new solution entered the beta it played a pivotal role in securing an enterprise account that nearly doubled the user base. The original codebase would have struggled to handle the account, whereas the new solution performed admirably. The enhanced UX from the new framework, and the new features and reports that were not possible with the old solution all contributed to winning the account. The new account became the first account on the new solution. Furthermore, being the first account on the new solution eliminated the need for migration from the old solution, avoiding a complex process that would have caused at least a 24-hour service interruption.

Putting it All Together

For optimal release success, it’s essential to incorporate features from all four buckets: growth drivers, customer features, improved UX, and internal fixes. Growth drivers ensure that the your strategic vision continues to provide the resources to invest in future iterations. Customer features ensure that your customers see that their invested time in your product is rewarded by a company who listens and delivers. Improved UX helps to keep the customer delighted and highlight your ability to keep up with market trends.  And the internal fixes prevent bumps in the tracks from derailing your development train.

Conversely, omitting features from any of these buckets indicates exclusion of parts of your organization or customer base, ultimately impacting long-term success.

Consider where you place features on the roadmap. For large projects development is most often broken up into two week sprints with a series of sprints leading to a “Minor” release (1.1) every quarter, and a “Major” (2.0) release every year.  In the case of Minor releases you will likely focus more on customer and internal issues, while Major releases will likely contain more growth drivers and UX issues. Alongside the Minor and Major releases you will need to have regular patches that address bugs according to your SLA. It’s worth noting that many enterprises prefer not to introduce new features in patches.

Regardless of release type, prioritize a well-rounded set of features to satisfy both customers and internal stakeholders.

As a long time product manager I have had to develop many new applications and features. Over the years I have learned many lessons. The below guidelines will help you design a good user interface (UI) by focusing on developing a successful user experience (UX).

This article will not focus on specific points of style. Whether you are building a consumer or enterprise product style is very important, but that I’ll let the UX designers cover that topic in more detail.

These 10 guidelines should apply to all features, large and small.  Whether the feature is simple or complex a product manager should think through the guidelines I have listed. I have learned the hard way that even small tweaks to an application can benefit from these guidelines.  Something as simple as whether to use “Close” or “Cancel” can make a big difference.  (see a Cautionary Tale: Cancel is not Close).

#1 Understand the Original Pain Point

It is important to understand why this UI/UX feature was requested (e.g. problem is it trying to solve). If it was a customer request then discover what the original reported problem was (note: this is not always what has been escalated).

Once you know the original pain point ask yourself “Are there any other related problems that can be solved?” Often one thing leads to another.  While you want to be careful of mission (and feature) creep you also don’t want to stop short of thinking through an issue. For instance when I was asked to add Active Directory (AD) keywords to the user profiles of my last product I could have easily added the keywords to help admin’s sort their users, but stop short of solving the real pain point of  providing AD based permissions .

#2 Get To Know Your Users

Understanding your users helps and what they are looking for help you solve a user’s problem in a way that they would expect them to be solved.

Don’t stop with just the persona that is requesting the feature, where a persona is a fictional stakeholder (e.g. user). Ask yourself if there are any persona’s that might object or be confused by the new feature.

Note: A persona  may include a name, picture; characteristics, behaviours, attitudes, and a goal which the product should help them achieve.

Find out as much as you can about all the personas that use your product before you start.

#3 Define the User Story

Do not assume that others on your team have your same understanding.  Ambiguity can easily slow development, irritate the team, and produce lots of bugs.

Whether you are using Agile or not you should always have a user story for every features and thus every UI element.  A user story goes like this:

“As a <role>, I want <goal/desire> so that <benefit>.”

See other alternatives to this format here.

Whether it is a simple button that needs to be added, or a complex user experience you need to be clear on the user story before you begin the design.

If you are working with a UI/UX designer review the user stories with them.   Let them ask questions, and give them answers.  Debate those answers.  Often this debate will result in a better understanding of the pain points and the persona’s involved.  This will also test a user story’s merits, if you can not convince the designer that the user story makes sense you may need to reprioritize.

#4 Develop An Initial Wireframe Workflow

So, now that we know who our personas are and what problems they are experiencing, we can start creating a wireframe, right?

Wrong.

One of the common mistakes I see in many applications and websites is poor workflow.  A feature is technically available, but it is hard to find, or it is found in one location, but not another.  It is always useful to walk through the user stories and see if there are any alternative workflows that make sense.  For instance:

• Are all your users going to start from the same place?
• Is the feature available if a user is not logged in?
• Is the feature different when a user is not logged in?
• Is the UI different for different users types (admin, user, guest, etc.)?
• Does (or should) this feature require permissions?
• Is this current UI the real problem?
• Should this new feature be applied to similar functions?

Really think about the last two question. It’s tempting to want to not over complicate things (e.g. use the KISS principle); however, sometimes fixing a bug or adding a feature is just scratching an itch and the real problem won’t go away.  Adding something will inevitably lead to new user expectations. For more read a Cautionary Tale:   Unexpected Consequences and  Permissions Permissions .

#5 Develop A Successful User Interface

It is time to start thinking about how to simplify the user experience so that users know how to find and take advantage of the feature. It is very important to communicate effectively to the user.  I have been shocked how many times a simple UI mistake has ruined a new feature.

• What language should you use?
• Is there a need for an icon?
• Does user need confirmation?
• Would a pop up / guide message help new users?
• Should you have a link to more information?

Word choice can make a big difference.  A clear and short title helps users understand features. Icons can help users find features, and often can assist in understanding.

Complex features may have different options that require a bit of explanation.  Sometimes that can be handled inline, but too many options or text might overwhelm or confuse the user.  Offer too many options and the user will probably do nothing. So choose wisely. Be sure that everything you add has a valid reason for being there. If it doesn’t solve a problem remove it.

Read  Attention To Detail for an example.

#6 Review Usability

Now that you have solved the user story, and started to develop a solid UI it is time to analyze your UI for usability. You have hopefully already looked a It is your job to ensure that your users not only understand the feature, but that i want in the quickest, most effective way possible. Problems might include:

• Not optimized for mobile
• UI too busy or font and icons too small
• Not accessible to screen readers or color blind people.
• Load time is too long
• Too many steps in sign up flow
• Is there help?
• Do you have examples?

If you are developing a product that is web based you need to think about mobile. Even if your target market is not mobiel you need to consider that  54.34% of web browsing is now done via mobile devices (source: W3 May 2017). With the majority of users on mobile even if your niche of users is not mobile heavy there is likely going to be some crossover.

Another point to consider is that if your product is not mobile, maybe you should add a mobile app to compliment it.

Whether you are using mobile or not you need to think about how visually friendly the UI is for the average users.  Icons are great, but are they big enough to see clearly (or too big)?  Are there too many icons? ¹ Are you including too much text? Are the icons obvious to the color blind?

When a user opens your UI they should immediately see how it can benefit them.  If they do not then they will likely leave and won’t come back anytime soon. To help with this you can add some guides that explain the user interface.  Having user guides is extremely important if you are:

1. Introducing a new UX
2. Using a UX that might be new to your audience

When “swipe right” was first introduced it needed to be explained.  Once it had been in use for a few years with trend setting apps like Tinder many people thought that swiping was obvious to everyone and started to add it to all sorts of apps including enterprise applications. The problem was that many enterprise users were not Tinder users. Not only did users find the application difficult to use, but enterprise users were not happy to find out that they were not hip enough to use the new UX.

Bottom line: A good UI does not need to be explained.  This was pointed out to me a few years ago by a customer.  I had redeveloped a complex UI and had added a whole bunch of tool tips and popup guides. I thought they were necessary due to the complexity of the UI; however, how could I argue with the statement “A good UI should be obvious”.  I had a lot of room for improvement.

¹ Many years agoMicrosoft Office switched from having multiple independent tool bars to a single ribbon menu scheme. I believe the idea was to avoid the problems with multiple toolbars taking up so much space. The new ribbon also allowed them to increased the size of some of the more important icons. Both problems were important to fix; however, I was irritated myself since I was comfortable with the old system and had created custom toolbars that were no longer available. Worse, I noticed that most of my coworkers were confused by the changes. My coworkers were simply overwhelmed with the choices and often could not find the features they were looking for.  The ribbon was a new UX concept and took awhile for users to adjust.

#7 Find Ways To Encourage Users

This often leads to frustration, and for the user to blame you and to instantly lose trust.

#8 Add Rewards and/or Gamification

Gamification does not apply to every feature, but give it some thought.  How can you reward your users for using the application, using the feature?  Is there a reward that you can offer? Can you at least congratulate them in a human tone?

Reward your users and they will feel compelled to use your product. Make them feel loved. In turn, they will love your product.

To be clear “Gamification” does not mean that you turn your application into a game. It simply means that you are trying to use the principles of gaming to encourage the continued use of your application.

#9 Consider Analytics

Whenever possible add analytics so that you can determine in the future if you have made the right choices.  You are not always going to make that right choice.  Worse, users are not always going to tell you when you got it wrong.  In fact, most of the time users will never tell you they have a problem.  They just won’t buy, or will stop using your product.

You want to be able to analyze what features, and options, are being used.  The more feedback you can gather and analyze the better you will be able to refine your application.

If you have already added analytics to your product then you need to review what the analytics is telling you as far as the importance of the feature.  I’m sure analytics was considered as part of step 1, but now that you have moved forward it is a good idea to check again.  Based on the current analytics is the feature still worth developing? What are you hoping to gain?

#10 Define the Scope and Roadmap

Now that you have developed the user story(s) and workflow(s) and considered the UI you need to determine if the feature should be developed as a whole or in increments.

After fully analyzing a feature request, developing the user stories, and considering all of the unintended consequences you may discover that you have an Epic and not a feature.  You then need to consider if you have the bandwidth to handle the whole feature set in a sprint or two.  You might even need to span a feature across releases like I had to when I implemented AD based permissions.

If you have slid down a slippery slope and can’t figure out how you are going to climb out of the hole you dug, don’t worry. Start reviewing the stories and placing those that are needed first (the predicates) at the top.  Sometimes this means that stories that solve high priority pain point will be lower on overall priority because they are dependent on the other predicates stories.  Make sure that you link the issues together. It is important to note that as you build a ladder of features that some of the features at the bottom rungs  won’t be obvious advantages.  Often they are backend changes that development needs to make before the real pain points are made.

It is important to be as transparent as possible and communicate to everyone what is going on. Let development know the end goals, let sales know where you are headed,  and when appropriate let customers know that back end changes are happening.  Sometimes you won’t be able to show immediate progress, but as long as you keep communication going you should be good.

Bringing it all together

Whether you are fixing a UI bug, adding a small feature, or creating a brand new UI take the time to pause and think about the long term effects and goals of your product roadmap. In many cases you will be able to run through the above steps quickly- after all not ever problem is complex. When you do encounter a pothole in the road then take the time to explore fixing it. While often you will chose to delay filling the pothole, your analysis will help avoid passing by potholes that grow to upset the customer experience or those that grow into sinkholes that might swallow your forward progress.

Cautionary Tales

Cancel is not Close

When redesigning QMetry Test Manager we decided focus on providing a multi-tasking UI/UX. Users had been consistent in complaining that the old UI did not allow them to view multiple asset at the same time. To solve this problem we developed a desktop like UX that allowed users to open windows. ¹ The standard window template had an OK and Cancel button to allow users to close the window. This template worked well in almost all cases; however, we had a subset of windows that allow users to take multiple actions. Each action had a separate confirmation so those windows had the OK button removed; however, the Cancel button remained. This consistency was correct, right?

Wrong.

Because we chose to use “Cancel” users felt that it should cancel the previous actions. Many users were confused and afraid of clicking on the cancel button. When the user base was small the problem and was easily explained away and was unfortunately ignored. Eventually a large enterprise customer’s not only complained about the UX, but submitted a “bug” that the Cancel button needed to be fixed– they were requesting the Cancel button to Cancel all previous actions. ² Changing Cancel to Close was no longer an easy text fix, and the relationship with our largest enterprise account was strained.

¹ Many criticized the use of windows UI framework for the new UI as “old technology”. Some of the fiercest critiques came from UX specialists who wanted to use the latest technology and make the UI “mobile friendly”. The reason we chose a windows framework was A) it solved the main UX pain point of multi-tasking B) All our potential users were very comfortable with it which improved user on boarding (another pain point) C) after multiple trials with a separate mobile application we had concluded that our user base was not interested in using our service on mobile phones (Note: Our windows based web interface did work with mobile browsers if needed).
² The request for Cancel to Cancel all previous actions was actually greeted by development as “a feature request not a bug”. The feature vs bug debate is common between development and product managers and is worthy of its own article. For now I’ll just say that I agreed with development. Not only was this a feature, but it was actually a very complicated feature that involved a few technical challenges. To the user the problem was small and simple; however, the solution would be difficult, take a long time to develop, and would not produce a value add.

Providing AD Based Permissions

One of my largest customers requested us to add Active Directory (AD) keywords to our application. They were using AD to keywords to organize their thousands of users and wanted to use the same keywords to organize the users in our application. Since we already supported AD the import of the keywords was actually very simple to add. We could also easily add a column to the user list for the keywords to allow the admin to sort and filter by keyword. Unfortunately, the real pain point was not sorting or filtering. What the admin really wanted to do is assign permissions to our application based on the AD keyword.
This was a problem for many reasons too technical to go into here, but suffice it to say that had we moved forward with only the original reported pain point we would have not pleased the customer. As it was we had to create an Agile Epic issue which we broke down into separate features that we implemented incrementally.

Unexpected Consequences

When I took over product management for cloud based test management software I discovered that the the development team had added the ability to delete requirements.  This was based on a customer request; however, the customer had only asked for requirements to be deleted and not to delete the core data type used: test cases. The button was placed in an unusual location which made it hard to find.

After the initial release few customers were pleased and more customers were actually upset with the limitations. Instead of the new feature showing our users that we were listening to them, they took the new feature for granted and wanted more. Due to the complex nature of our SaaS application and the database schema we could not add the ability to delete test cases without considering a host of complex use cases- some of which were technically unfeasible.  Too late, we were headed down a slippery slope…

Moral: If you are going to do something, then do it right.

Permissions Permissions

A second problem that was created when delete was added to the application was that the original customer just wanted the delete feature.  They had a small flat organization and didn’t care who had the ability to delete an asset.  This did not work for our other customers who either wanted no one to be able to delete items, or wanted the feature limited to specific users.  Adding a user permission for delete had to be considered a requirement for the delete- and many other features.

Attention To Detail

One of the last bugs I solved with QMetry Test Manager was to unify the dialog boxes so that the escape button would always close the dialog box.  Believe it or not this was a big problem for us.  Why?  We had tens of thousands of core users that preferred navigating with the keyboard for speed.  We added keyboard hotkeys to improve the UI for them; however, this caused a bigger problem.  We started to field complaints from our enterprise users- the management team – because users were complaining of inconsistent behavior.    The original spec had defined the dialog boxes to have a close button; however, after v1.0 the original spec was rarely referenced and many new team members had never seen it.  Since a dialog box was so simple it was rarely mocked up which led to many new dialog boxes were created without a close button.  So, when we added hotkeys many dialog boxes would not close with the escape key and our power users complained.

Why was this a bigger problem?  Before the users were making a feature request- hotkeys.  Now they were reporting bugs and telling their management about an inconsistent UI.  To make matters worse other inconsistencies started to be highlighted!  The fix was simple, but finding all of the dialog boxes was a chore for development and QA.

Note: In case any of you think that development should have kept following the original spec.  Yes, in a perfect world that is true; however, if you expect a perfect world, and don’t want to take responsibility for the imperfections then don’t become of a product manager.