This bothers me a lot as a UX Designer, I see it from Fortune 500 companies, to venture funded Silicon Valley startups, to some-guy-in-a-basement startups. The issue has to do with how new features and new products are defined. Regardless of the client’s experience building digital products, SaaS, mobile apps, web apps, the majority generally tend to screw this up. As a Product Design Consultant, I haven’t worked on one feature where I didn’t have to provide clarity to strip down and simplify the scope. The real issue is that the client tends to give little thought to the product scope (amount and complexity of features) for the first version and how it feeds into the second version, through user feedback and analytics data, and how that feeds into the third version. Whatever you think your Minimum Viable Product is, can be stripped much further down.
I have a few theories as to why clients make this mistake.
They’re too passionate and excited about the new feature or product, so there is a lot of attachment to the final product vision, which makes for emotional decision making
They have a really grand vision and they *think they’ve stripped down the scope to the core, when they haven’t
They think they have to build everything because of a bureaucratic reason
They think the user won’t like the feature or product, because the real value is in the combination of all of those features being in one place
This mistake is important because building too much, too fast, will create a larger time frame between their starting point and their point of receiving positive feedback from users (qualitative feedback, product market fit, user analytics data or some KPI). This larger gap will lead to them running out of resources faster, whether it’s funding, or psychological motivation to continue.
I will use a couple of examples based on real clients I’ve worked with to explain my theory and how to go about the thinking.
1- The client was building a SaaS analytics dashboard for an enterprise use case. As with any data visualization dashboard, giving the user the ability to see an overview snapshot of data to answer their underlying business question is the primary goal, and the secondary goal is for them to dig deeper into specific data points to further uncover information that will guide their business decisions. The first step is to build the primary overview dashboard with the snapshot 30,000 ft view of the data and optimize that in the first version, then focusing on iterations. The second step is to build the deep dive views. If there is no interaction with the overview of the data because it’s deemed not interesting enough, because it’s answering the wrong business questions that the user doesn’t actually care about, then the deep dive views don’t matter, the user won’t try to dive deep into something irrelevant. The way to measure the interaction with the snapshot view of the data without having built the deep dive views was to allow click actions into that overview data, but just provide static deep dives, rather than fancy interactive deep dives that lead to more deep dives. In short, the secondary view, which in this case was the analytics deep dives, had to be stripped down a lot.
2- The client was building a social application. “We need the ability for users to comment, and for other users to respond to these comments via text, voice, and video.” If the initial user doesn’t comment, the corresponding feature of text, voice and video is utterly useless and literally unusable in the UI. So we built the initial comments section, measured the interaction using an analytics tool, or sometimes manually tracked what percentage of users left the initial comment. The idea was that if that percentage is high enough, we would continue with the rest of the product hypothesis, if it’s low, rethink the initial comment.
In short, design the core, core-core, like the actual core. Then strip it down further, and build it. And measure it, optimize it. And once it reaches a certain level, then you can start to build the rest, otherwise “the rest” will never be used, and won’t be given a fair chance to be measured.