Users > features

Great Design is the next frontier for traditional companies getting into the digital business. The journey to delivering value through software began with Agility, and continued with DevOps, but needs to go one step further.

This is well understood by the most successful tech companies out there, and even though everyone agrees with the idea, we still see and use terrible software (especially if you deal with B2B software, made by some companies that were neither born within nor led the digital world of the last 10 years)

This image is probably > 10 years old, yet still relevant

I saw that graphic for the first time probably 10 years ago, laughed, shared, and moved on. Recently, I went through a few meetings that reminded me of it, and I realized it’s still relevant!

But why? With all the resources about Product and Design available online today, with all those product companies reaching records profits and valuation showing the path, why is it still not the norm?

My take is that people think about features a lot — too much — and not enough about users. Especially in big traditional companies and despite them saying the contrary. Especially people who still don’t know the difference between a Product Manager and a Project Manager. Especially people who think designers come only in the all-in-one package of “UI/UX”.

Google, Apple, and all the successful tech companies “of the internet era” have very simple products in appearance, but their complexity — under the hood — is often greater than traditional companies’ products. That is the beauty of good design: it makes complex things look so easy!

Thinking in features and specifications

A feature, also called sometimes “functionality”, is, as the name suggests, a function. So a feature, like functions, transforms a series of actions into an outcome that provides ideally value to someone.

But the value is not inherent to the feature. The value is linked to when, and who uses the feature (a.k.a. “The User”)

Customer or user-centric, an example

Everyone wants to be user- or customer-centric. But most people are talking daily about features. Not users. On Confluence pages and in Powerpoints are feature lists. The backlogs are lists of features. Especially in the enterprise world.

Usually, only Designers and “real” Product Managers think in terms of users and customers. Here’s an example of what happens when you reason only with features.

The user role: “Traveler”
The feature: “Book a ride on-demand, from A to B, using a smartphone”

This is simple enough. As soon as it’s built, you can put in your sales decks, presentations, and documentation that your product is able to handle a modern “book-a-ride” feature, like “Uber”. People can demo it and sell it.

But here’s a quick-and-easy look at what happens if you put the human and customer first, within their context:

• Traveler John arrives in a big city, in a foreign country, and now wants to go from the airport (A) to his hotel (B). He doesn’t know what’s available around in terms of transportation.
• Traveler Paul wants to get to work (B) in the morning, from his home (A), using the app of the only Public Transit Operator of the city.
• Traveler George is in Las Vegas for a big conference and has to go from one end of the strip (A) to the other (B) between sessions.
• Traveler Ringo works in a big private industrial complex and needs to move from one building (A) to another (B), using a semi-autonomous shuttle provided by his employer as a means of transportation.

4 users, 4 use cases, 4 market segments, still the same feature. When the sales team talks to the 4 different customers (the “PTO”, the taxi company, the event organizer, and the big company), they will say each time that we have a “booking feature”.

But all 4 use cases could require dramatic experience changes.

What I usually see unfolding is the following:

1. Business identifies a first use case and works with Product, Design, and Engineering to deliver a first “MVP”. That is: an interface on an app where you can enter A and B, and get a vehicle coming to you. This demonstrates technical feasibility and covers the basics of 90% of the identified “book-a-ride” opportunities across segments.
2. … 6–9 months later, what remains of this effort is “the feature”, in a feature list, more or less well documented.
3. Business or management wants to sign with a new customer because it could be a new interesting market. A customer is a customer, right? And their requirements match 1–1 the “feature list” (a.k.a. “We tick all the boxes!”).
4. Software is delivered easily, but the friction is high for users at this customer.
5. Bugs and improvements tickets start flowing into the support team (also: bugs disguised as improvements, and improvements disguised as bugs). Product and Design are not in the loop. They did their work already, and if we involve them with every new customer, what’s the point of building a product in the first place?
6. Engineering teams tackle the support tickets, without being aware that they are actually delivering a brand new market, brand new context, and different “personas” (at this point, few people are aware).
7. A small checkbox, a quick new button, and another input field there. It’s still a booking feature. But it’s getting bloated.
8. …Iterate a few more times, and you get the 3rd picture above
9. Everyone has the feature, but everyone is slowly getting more friction (even the first customer, who had the perfect solution, in the beginning, is getting more stuff he didn’t ask for and doesn’t know why it’s here).
10. If you are a traditional company addressing consciously or not multiple market segments, this is the perfect ground for a startup to come and “disrupt” one of your markets. Not because they are more agile or deliver quicker. But because they will work closely with “your users” where you didn’t. Alternatives arise, and market shares are lost. Lack of agility is blamed, where it was actually the lack of thinking about users and markets first.

PM vs. PM, UX vs. UI

“But.. we have designers and PMs in the org”

There are designers and “PM” in most organizations. But

• Is the difference between Project, and Product Management understood?
• Is the difference between managing a roadmap, and managing deadlines understood? (Is there even a roadmap or is there just a backlog in Jira?)
• Is the difference between feature lists, and delivered value understood?
• Is the difference between a UX researcher, a UX designer, a UI designer, an Interaction Designer, and a graphist understood?

In most traditional organizations, Product Management is mistaken for something else. There is no one to blame, it’s just the context and history. But it doesn’t mean it shouldn’t change, and that people shouldn’t get trained — both the “PMs” and the person hiring them.

You can also see a lot of “UX/UI designers”. And even if most of them are great designers and understand better the users than anyone else in the company, they are often relegated to a “delivery role” where they build design systems, and icons, and choose colors. Because that’s what non-designers think Design is. Worst: in a lot of cases, they don’t have access to users directly.

What about Agile and DevOps: they were supposed to help here!

Both are recent, modern, and necessary mindsets — or sets of practices. The transformation to Agile and DevOps is necessary to get a traditional company from “IT” to “modern Software Engineering”. The catch is that even though both are advocating to put the “customers” and “users” first — the Agile manifesto is explicit about that, and DevOps is all about delivering value continuously to the end-user — none are telling you who the customer is, what is their context, who are the users and why you should be considering them in the first place. Good Product Management and good Design can help you with that.

Switching gears and really caring for users

Users vs. customers

Sometimes, the user is the customer. Especially in B2C. But not always. That difference is fundamental, and in my opinion also a reason for the mess we can find in the B2B markets.

• The User Experience designer takes care of the user (their context, human traits, emotions, messy behaviors, etc.)
• The Product Manager takes care of the customer, their context, their business traits, their market constraints, their needs, and priorities, etc.)

Users today have more expectations in terms of usability, more choices, and more influence regarding the software they will be using than before. Considering the customer only is not enough. If the friction for users is too high, the ROI goes down for the customer.

Put the feature in the right context

Every feature ever should be tight to:

• A persona (users)
• A market segment (a customer)

But I rarely see that in either “Jira tickets” or product documentation. If that information ever existed at all, it’s usually constrained to designer teams’ tools and documents. User stories are supposed to have “the user” embedded in the requirement. We never see the personas there (“As Ringo, I need to have a vehicle waiting for me next to building A, five minutes after my meeting is finished, so I can reach building B on time for my board presentation”)

Reusing features and technical components because on the paper they check all the boxes can help sometimes with deadlines, but it’s very short-sighted. It leads to bloated software in the long run and diminished value.

Final word

Designing for the end-user is mandatory today. And if your users have no personas, no context, then you’re not designing for the user. You’re designing for a generic role and you will not be able to see the subtleties of the needs over time (like the simplified “Traveler” example above).

Designing the Product is about making sure someone is going to use — and pay for — it. Hence creating the value.

Traditional companies are still in the middle of their transition to Agile and DevOps. Now they need to focus on Design. Even if it’s obvious for a lot of startups and communities, it’s definitely not the case in most companies.
.. And since I’m talking about traditional companies, I’ll put a McKinsey link and quote, to support the claim and make “decision-makers” comfortable :)

…with organizations that have invested in design exceeding industry peers by as much as 5 percent per year in growth of shareholder return

Stop dropping requirements to Engineering teams. Hire — or train — good Product Managers, let them define what customers should be addressed and what should be the priorities, put your UX designers in front of those customers, and let them map user stories. Stop using the backlog and the “feature list” as the definition of your Product. Start talking about users, market segments, and the actual value. The nice side-effect of this is that suddenly, deadlines will become less important since usually, users don’t have problems starting on a specific date.