If you follow me on Twitter, by now you’ve figured out that I’m really picky about products: I’m constantly finding mistakes, bugs, and/or issues in everything that reaches me as a user/consumer — which is a lot, because I’m an early adopter and like to test everything that comes out that could make my life easier or my work (with my team and/or clients) more efficient.
To satisfy my obsession with better-made products, I created a startup focussed on collecting user feedback in a social environment called CMPLAIN, with the tagline “Improve your world”. Unfortunately, after releasing the beta I’ve learned (together with other startups in the industry) that monetizing “negative” feedback is a hard task; companies prefer to keep their products and service’s shortcomings private. I’ve learned a lot from this experience; it has especially fuelled my attention to detail and raised my standards to extreme highs. But I’ve also learned that finding problems is innate for those creating products, not just using them.
I’m the CEO and Product Designer at Bons, a digital agency where we work with startups. We created an amazingly polished workflow — we get things done at a speed and quality that only startups working for many, many years can hope to achieve — and build our team to not only create solutions but also to find problems before the user does.
Many design professionals (including myself) would define design as “the practice of solving problems”. This helps us to separate design from art. But with this definition you would think that as digital designers our job is to create the digital solution to the problem you, as entrepreneur, have already found and that led to your startup idea. But that’s partially wrong. Yes, you found an issue and you thought of the business solution, but when creating a new product, or improving an existing one, there are many other problems only product designers can successfully find and solve. Here I’m going to talk about two kinds of problems: execution problems and experience problems.
Time after time we encounter founders who are not technically savvy and have perfectly reasonable ideas that can be translated into products or features that are technically improbable (there is nothing that is impossible, just too costly in time and/or resources to be considered probable to pull off). As product designers our job is not to discard these ideas, but to find the most efficient and cost-effective way to make them a reality.
Failing to identify execution problems could lead a startup to burn all their resources and even go bankrupt before getting close to finishing their product. Founders need to pay a lot of attention to this, as it’s common for the technical people on a startup to either hide or fail to communicate these problems due to over-confidence, fear of failure, lack of experience, or a mix of all three.
Planning the future while working in the present
There are a lot of management techniques, strategies, and models such as lean, agile, and waterfall. In my experience, choosing one and following it blindly is not the best approach. At Bons we went through most of the models, and what really ended up working the best was a combination of everything, leaning toward one or the other based on the project in hand, but keeping foundation behaviours and habits that we are constantly improving and building upon. The process is there to serve us; we are not there to serve the process. For example, when we start a brand-new product we normally do waterfall of the first core features to reach the MVP. So we have something we can put in the hands of the first testers (or users, depending on the go-to-market strategy), and from there we use a mix of lean and agile, trying to fit as much as possible into weekly sprints. Agile development normally considers sprints to be two to three weeks, but we experienced better results when having shorter time frames; this way we avoid bigger delays and can reschedule what we are doing to accommodate current needs. Our sprints may be longer when tasks are more complex, but we always test and deliver progress every week; that’s the priority.
Startups are driven by present needs but defined by their future. What is getting done today is defined by the long-term goal. SpaceX’s future is to colonize Mars, and for that they need to make rockets more cheaply. But that doesn’t mean that the rockets they are building are not providing value to the market and revenue to SpaceX.
Each part of the roadmap, each planned feature or improvement, is a whole on its own. It’s what the user perceives in the final product, and it’s reinforcement that even when they are paying for today’s product they are contributing to the final vision; by using the product now, they are getting front-row seats to the future. With our products (our own and client’s), we create wish-list documents where we describe what we want to test and what needs to be done, and we schedule the tasks in order of priority in a weekly roadmap. This roadmap is in constant flux; we reorder priorities or add new features as we learn they are needed (or to address experience problems that have been found).
We normally address features in different versions. First we create a “v1” which contains the best possible experience with the least amount of effort. This allows us to search for experience problems more efficiently and avoid interminable lean cycles.
There are many products that are conceptually amazing but the experience is so horrible that they end up being a waste of money and resources. When I’m referring to “experience problems”, I’m talking about everything that could be improved to make the user’s life easier when using the product, from micro-interactions to the biggest task flows a user can perform.
The easiest way to find experience problems is to simulate as close as possible the product experience (duh!). We normally find ourselves going through the different interaction scenarios to discover problems and find the most logical path to a successful experience. For this we use small whiteboard notebooks and start sketching things out. This helps us understand when something is not how it is supposed to be when testing the production-ready version and also is what guides us to the final version with fewer unanswered questions.
Experience problems are the ones you solve to make your product better, and it is a matter of life or death for a business to give experience problems the importance that they deserve and need. If you just focus on surviving with a mediocre product, you will do just that — survive — when you should actually aim to grow and be a dominant force in the market.
Peter Thiel says in his book Zero to One, “You can radically improve an existing solution: once you’re 10x better, you escape competition.” He explains that for a business to really reach success it needs to escape competition and become a monopoly, enduring in the future and dominating the market. He also points out that one of the characteristics of a monopoly is having a better product than your competition, but I believe that besides having a better product than your competition, you should always aim to also have a better product than the one you have now.
Let’s take an example used by Golden Krishna, author of The Best Interface Is No Interface: the app BMW created to allow BMW owners to open their cars. The idea is great; you could open your car with your phone and forget about those 6000-year-old pieces of metal you carry in your pocket. Who would not use this? So based on that idea BMW made the app, which requires you to take all of these actions to open your car:
- Pull out the phone
- Wake up the phone
- Unlock the phone
- Exit the last opened app
- Swipe through a sea of icons, searching for the app
- Tap the app icon
- Wait for the app to load and try to find the unlock action
- Make a guess with the menu and tap “Control”
- Tap the Unlock button
- Slide the slider to unlock
- Physically open the car door
This is a horrible experience that screamed problems on every single interaction. You don’t have to be a professional problem spotter to see that this app would certainly fail. But that app actually went out to the public, going through the hands of hundreds (if not thousands) of employees and executives. I doubt that all those people are just idiots who couldn’t see the problem. I’m more inclined to believe that these problems occurred when the designer (or product team) failed to speak up about the shit experience this app ended up being.
Sugarcoating or just not saying anything when you see a problem is one of the most dangerous threats a startup (and any kind of business) is facing. But this is actually normal behaviour. How many times have you found yourself in a restaurant criticizing the service or the meal with your friends, and when the waitress comes to the table and asks, “How was everything?” you reply with a really gentle smile, “Everything was great, thank you.” (You even say thank you when 10 minutes ago you were like: “I’m going to say something, this is so wrong!”) And the worst part: do you know what’s going to be improved in that restaurant the next time you come? Nothing!
Well, this is the same shit that happens in a startup. For not confronting the founders or team leaders, for being scared of being fired or just for not wanting to separate themselves from the team, employees tend to shut up. This is extremely dangerous, and more harmful than actually being an idiot and not seeing the problems.
I like to speak up. I not only tweet to companies but also engage their support and in some cases their founders to give them honest negative feedback. Why? because the only way to create solutions and improve things is by finding problems. I’ve found that the most successful startups I’ve engaged are also the most grateful for this kind of feedback. One of the most responsive ones was Webflow, to whom I’ve had the opportunity to give feedback from the start. Not only did they appreciate my feedback, but they encouraged me to keep it up (and I did).
This is natural to me. Some would consider me a grumpy user/customer, but those who know the value of problem spotting are normally really grateful. And for me it is actually just training my problem-spotting skills that I apply daily at Bons when creating products for ourselves or our clients. Of course I also have the advantage of fewer consequences for speaking up than the average employee might have, but working with founders or teams that don’t appreciate this behaviour is honestly a waste of time: their products will usually suck and eventually fail.
As designers we are trained to be highly empathic individuals. Our job is to predict what people will feel when experiencing the solutions we create for them. One of the biggest dangers is being self-centered: focusing on what we like, feeling proud of what we’ve created, and not taking the time to actually find the problems before jumping to create the solutions. We must feel the user’s pain as our own to find the right problems and design the right solutions.