Bringing Analytical Thinking to Product Decisions with Client Teams
Taking an analytical approach to evaluating decisions leads to better digital products and happier clients.
What is decision-making? In its simplest form, decision-making is the act of choosing between multiple courses of action. When confronted with a decision, you can take one of two cognitive approaches - analytical or intuitive.
In Thinking Fast, and Slow, Nobel prize winner cognitive psychologist Daniel Kahneman describes analytical thinking as “slow, deliberate, and consciously effortful mode of reasoning.” By contrast, intuitive thinking is our “fast, automatic, and largely unconscious mode.” In other words: think, or blink.
There are hundreds of non-trivial decisions that come up in our day-to-day work building brands and creating great web products here at Viget. Which typeface combination best conveys a campaign’s tone? What mobile nav style will work best for users in an older demographic? How should I structure the code for this feature? Our professional lives can be simplified down to making and acting on decisions like these.
When we can, an analytical approach is almost always the better fit for these decisions. A visual designer can experiment with different typefaces, an interface designer can test mobile navigation patterns with potential users, and a developer can look at comparable code from peers, all in their quests for the best solution.
Sometimes though, we do need to rely on intuition to make a decision. That’s not necessarily a bad thing! The “gut reaction” of an industry professional is backed by years of experience, training, intimate knowledge of web standards and best practices, industry know-how…and of course (as Kahneman is quick to point out) a sprinkling of personal preference and bias.
What kinds of product decisions do we make with clients?
When we’re building a web application with a client team, we often lean on our clients to help us make some of the toughest and arguably most important decisions of the project:
Should we prioritize feature X or feature Y?
Is it more important for feature X to do (or look like) this, or that?
How do we incorporate requirement Z into the existing design of feature Y?
We value our client’s input and want them involved in the process. Clients are often much more intimately familiar with the subject matter and users for the products we’re developing. And, like any consultancy, we need their buy-in.
Just like in our internal, day-to-day decision-making, we want to be able to take an analytical approach to decisions we make together with our clients. The most straightforward way to achieve this is by validating decisions through lightweight research and testing. But research data isn’t always available and decisions still have to be made.
If you were to ask a client team “Should we prioritize feature X or feature Y?” and you didn’t provide any additional context, direction or a framework for making an analytical decision, you are inadvertently asking them to use their intuition to make a quick decision. In other words, “What do you think?”
Client teams are equally as invested in the product’s success as we are, and they don’t ever want to rely on a coin flip to make a tough choice. Clients want to make well-informed decisions, and feel good about making them! But our client teams are also (in most cases) not web professionals. They don’t have the years of experience and training that might otherwise arm an intuitive decision. They have emotion and preference to inform a quick decision, and whatever information and experience we’ve provided them to make an analytical one. If we don’t provide a framework for that decision-making, we haven’t served our clients (or our product) very well.
Taking a step back
It can be tough to have future-proofing conversations when a project is first kicking off and everyone is excited and getting to know each other. But, early on in a project is actually the best time to introduce clients to the possibility that tough conversations may happen down the road. The moment when you’re asking a client to choose two features from a list of five that will be finished before code freeze is not the first time you want your client aware that this situation might come up.
Within the first week of a development project, it’s a good idea to share two unalienable truths about software development with your client team:
We are almost always working under some constraints (often time or budget) that limit the number of things we can do. Software development is fluid; it’s not an exact science. Any number of factors can increase or decrease the amount of time one thing takes, so it’s impossible to predict exactly how many things we can do in the given constraints.
Application interfaces can accommodate a lot of different user needs. But the nature of design is such that the product interface won’t be able to satisfy every use case with equal priority.
Creating an analytical framework
Once clients understand that we are working together on a project for which we may not be able to do everything, the logical next step is recognizing that this situation will lend itself to hard choices. That conversation can go something like this:
“We will likely have to make tough decisions about what we should spend our time building (feature prioritization) and how those things should work (feature design and definition). There may not always be a perfect solution, and in those cases whatever we do will be a trade-off. The best we can do is to try to understand the priorities and the tradeoffs, make decisions together on the best way to move forward, and then work as hard and as fast as we can on what we’ve all agreed is most important.”
And now, the final step. To evaluate and understand priorities, work with your clients to identify a single most important user upfront before any development work begins.
We often ask clients to rank primary audiences at the start of the project. We define, design and build the product with those audiences in mind. But what if only one could be the most important? If you had to choose?
Certainly there will be product decisions throughout the course of the project that don’t pertain to this single use-case. For an app that allows higher-ed professionals to showcase their CVs and search for jobs, prioritizing the job-seeking professionals won’t have much impact on the functionality for job-posters. But as we’re designing the interface, defining features and deciding what enhancements are critical for the application, having a single user that everyone has agreed is most important is incredibly helpful.
It sounds pretty simple, right? “We can’t do everything, so we’re going to have to agree on what’s most important, so let’s decide who is most important, and that user will be our framework for evaluating decisions down the road!” Having these conversations with your client team requires tact, honesty and trust on both sides. Agreeing that tough decisions will be required means acknowledging that our development team may not get to everything. Agreeing on a most important user means acknowledging that other users may have slightly less focus.
Putting our framework to the test!
We recently worked with iContact to build a tool that allows people to edit email layout and marketing content in React. Our primary success metric was to increase the number of new trial users who successfully sent their first email. We also knew that most new trial users of iContact were first-time email marketing users.
Once we were all on the same page about the reality of having to make decisions to meet our ambitious launch deadline, keeping this user in mind helped us evaluate some of those toughest decisions we encountered on the project (alongside an unbelievably great client team!) such as:
Should we include preview text in the metadata area?
Is it more important for users to be able to crop and rotate images, or upload multiple files at once?
How should we treat the requirement for converting blocks to HTML?
In conclusion
Daniel Kahneman said it best. “If you’ve had 10,000 hours of training in a predictable, rapid-feedback environment — chess, firefighting, anesthesiology — then blink. In all other cases, think.”
In the same way that we think before we make major decisions, we want our clients to do the same. The more we can do to position our clients to make analytical product decisions with us, the better we can guarantee on-time and on-budget delivery of a user-driven product.
