RelateIQ is testing a new feature internally right now. It’s an update to its Chrome extension that will give users a simple way to verify a rule for an email they’re about to send.
The relationship management software already offers rules by default in its app. If an email goes without a response for a certain period of time, for example, a user is prompted with a reminder. The update to its Chrome extension though, will focus on additional rules, confirming they’ve been activated by changing the color of the “send” button.
The new experience for users, says Tim Fletcher, the company’s first product manager, leaves them saying, “I feel like I have a superpower.”
When this reaction is garnered, a product team has achieved user delight. It’s built a feature that doesn’t just work, it makes users feel good or powerful. It’s the pinnacle of what RelateIQ has come to call the “Product Hierarchy of Needs”.
Maslow Inspiration
You've likely heard of Maslow’s Hierarchy of Needs. Named for its originator, psychologist Abraham Maslow, the hierarchy is a concept he articulated in a paper from 1943 explaining human motivation. The idea is that a human being is going to focus on essentials first. He or she isn’t going to work very hard on higher achievements until food, clothing and shelter are sorted out.
More profoundly, he suggested that there are other human needs, including love and family, that one is likely to pursue before career achievement or spiritual fulfillment. The idea is that humans will put first things first. To put it dramatically, an individual isn’t going to try to write a novel if they aren’t sure where they are going to sleep tomorrow night.
The team at RelateIQ has realized there’s a similar hierarchy for product teams. When you have a complex product with loads of features you want to build, bugs you want to fix and performance you want to improve, you need some kind of way forward.
“The Hierarchy of Needs is, when you are faced with a bunch of decisions in your roadmap, how do you choose between them this week,” Fletcher says. “Well, if there’s any problem in your foundation, you need to face that first before you move on.”
In other words, one of your user experience team members may have come up with a really clever way to let a user set one of the aforementioned email rules, but if the email tracking system itself is delivering stacks of errors, that needs to take priority.
Here’s RelateIQ’s “Product Hierarchy of Needs”:
The Five Levels
The first two levels are easy. Is the site up? Performance also applies here. If it’s barely running or critical systems are breaking down, that doesn’t meet the “site up” standard. Bug free means features are working without weird hiccups under specific conditions.
The next two are more subtle. Functionally correct begs the question: does everything work the way it’s supposed to work? If you click three contacts and then click a button to put them in “Lead Category A”, do they get tagged as “Lead Category A”? Or do they get tagged as another category? Or do they not get tagged at all? If the code is not delivering what it needs to deliver, that needs to get dealt with first.
Feature correct is a bit more profound.
“This stage indicates that we are solving major problems for users,” Fletcher wrote on the RelateIQ blog. It’s one thing to do what the code says it will do. It’s another thing to do what users actually need.
User delight is the top of the pyramid. Does the feature not only deliver, but deliver in a way that gives users a positive feeling. Like power or happiness or thrill or a laugh.
Here’s an outline of the hierarchy, starting with the pyramid base, that Fletcher presents on the RelateIQ blog:
Site Up: If the site isn’t up, nothing else matters.
Bug-Free: If there are bugs, no user cares about the beauty of your product.
Functionally Correct: This level requires that our software works as specified.
Feature Correct: This stage indicates that we are solving major problems for users.
User Delight: This highest stage of product development brings relief and joy to the user.
The Hierarchy in Practice
As far as Fletcher knows, RelateIQ is currently the only one using the hierarchy to guide its workflow decisions. They came up with it about a year ago.
The enterprise company wants to be known as a startup that moves quickly. They regularly do a Sprint Planning meeting to look ahead.
“Pretty much every week, we have a chance to say: we are finishing a few things, what’s next? What problem do we want to solve?" Fletcher says. Inevitably, there are four or five things that are waiting to go out."
That’s where the Hierarchy of Needs comes in. Here are four examples of the hierarchy in practice at RelateIQ.
New Feature vs. Search Fix
The RelateIQ team recently had two ambitious ideas on the table. First, they wanted to build a new reporting feature for users at the manager level that would give them a big picture view of their team’s productivity. Revenue closed, calls made, all the metrics. It was important. It was powerful. It would not be simple.
At the same time, the developers could also see that their search function was starting to show signs of wear and tear. It wasn’t broken, but it was bending.
“This is foundational. If this breaks, that’s a problem for everyone,” Fletcher says. So they held off on building the new report until their search function was solid once more.
“For us, we could go on to solving a brand new problem or we could create some resilience and robustness in the way we are currently delivering the application.”
A Stop for a Style Guide
RelateIQ is still a relatively new company, constantly building out new features. Amidst this work, the product team realized the company’s overall design strategy was an impediment to rapid work. They were coming up with new design styles on the fly, each bringing its own set of meetings, conversations and sketches.
So, they decided the app needed a complete redesign and an accompanying style guide. That way, when new features came along, there wouldn’t need to be any meetings. Everyone would know how it should look.
“It felt like more of an infrastructure investment,” Fletcher says. The site was up but evolving too slowly because of all the design conversations. So this redesign was for the developers.
That said, as soon as they resolved to take the project on, the designers decided to take the time to make it as strong as possible.
“That’s one we said, we are doing this for reasons at the bottom of the pyramid—we need to develop faster—but we are going to take it all the way up if we are going to touch this, because we are going to live with this for a long time.”
Daily Standup Keeps Hierarchy Top of Mind
Every day, at 10 a.m., someone on the RelateIQ team rings a gong. That signals the start of the daily standup. The whole team gathers around. They have a big board that lists projects in play and features on the to-do list. There’s also a TV above the board that is constantly feeding out performance metrics for the whole system. This daily meeting guides the team’s work every day and keeps it within the company’s larger roadmap.“If there’s anything wrong with the site. Any slowness, any errors, that takes precedence. Those have to be solved before you get to other stuff,” Fletcher says.
The team has lots of features that they want to work on and that their customers want them to roll out. When users come to them asking when some feature they want now will come or why it hasn’t been built yet, they have found that it helps to use the framework of the hierarchy to explain to them the order in which they work.
“Despite the fact that we care so much about the foundation, customers trust us because of the velocity we release new features,” Fletcher says.
Which is not to say there is no discretion.
“One thing that I can’t stress enough: the foundation doesn’t always win. You don’t just keep building and building infrastructure. At some point you say, I think we’ve hit this level.”
He gave an example of another email feature they have built in. If a user wants, the system can help users keep track of unfinished business. So, for example, it can let a user know if they have had an email sitting without a response for too long or if a question the user asked never got answered.
Fletcher says that the ways of understanding this is imperfect. Not every question ends with a question mark. Sometimes they get answered face-to-face or with a phone call or with a text message. Which means sometimes a user gets a notification about unfinished business that is, in fact, finished. All things considered, the feature is a win for RelateIQ.
“The delight when we’re correct is so high, despite the fact that the error rate is non-zero, that it’s definitely worth it,” Fletcher says.
Functionally Correct vs. Feature Correct
One of the more subtle distinctions in the pyramid is “Functionally Correct” versus “Feature Correct”. A reader may be asking, if a feature works, doesn’t it work? Fletcher offered an illustration of the distinction to make it easier to understand.
RelateIQ helps users communicate with contacts. It also aims to keep track of every single way in which a team has communicated with a contact. You want to know when and how your customers have heard from you and how you’ve heard back and you want all that logged forever.
Related: Read how a sales app startup used RelateIQ and Zapier to speed up their sales process.
Fletcher says that they have salespeople who will want to email lots of their clients. To do this, they will use email platforms like MailChimp to make those mass emails. To facilitate this, right now, RelateIQ makes it easy for sales teams to export a list of emails that they can load into a program like that.
The feature works. It’s bug free, but that doesn’t mean it’s actually solving their users’ real problem. The real problem here is not just getting the email sent, but knowing that it was sent and exactly what happened. Right now, RelateIQ doesn’t natively integrate with those mass emailing services, so it’s not logging that the email got sent, who opened those emails, what they clicked nor is it making the connection between the email and the sales that follow it.
“That’s why we are working now on a way to connect up to those systems, so that users can automatically control their communication to customers without having to export it,” Fletcher says.
The Origin Story of the New Hierarchy
As stated earlier, RelateIQ prides itself on being a company that moves quickly. As the team grew, they realized that they needed a way to decentralize decision making across the company, so that small teams would know how to prioritize decisions without constantly coming back to the larger group.
Fletcher says he remembers the moment. The leaders of the company were together and looking at a six-month roadmap. They were aware that they were bringing on more and more people who hadn’t been there since the beginning. People who may understand the big picture, but not how to decide what was most important today.
“We had this long list of stuff to do that we couldn’t get done in the next 6 months and there was a lot of back and forth about what order to get done what we could do."
He remembers a consensus forming that the site had to work first and foremost. The rest gelled from there. They put it up on the board and realized it made a pyramid. Now that it’s in place, decisions are getting made faster, which was the goal.
“There’s less time spent debating things and more clarity,” says Fletcher.
Now Referenced in Office Conversations
The Product Hierarchy of Needs is now part of the language of the company.
“Any new framework takes some time to be fully embraced by the people who work with it,” Fletcher says. “It took a few development cycles to realize that it was no longer the people in that first room were invoking, but that everyone was fluent in it.”
He knew the idea had caught on when he started hearing it referenced in conversations around the office. When he heard developers arguing for pushing to delight and designers arguing for infrastructure, it became clear that RelateIQ had established a framework for collaboration that everyone understood.
You might also enjoy this article: “In the Age of Experience, Great Design is Your Business Plan”.
Credits: Photos courtesy RelateIQ.
