Hello, I’m Felix! Welcome to this week’s ADPList’s Newsletter; 🔒 subscriber-only edition 🔒weekly advice column. Each week, we tackle design, building products, and accelerating careers. We’re looking for sponsors! If you’re interested in sponsoring our newsletter, let’s chat.
The age-old question of whether designers should learn how to code has been discussed at length. However, I believe that designers should focus on product thinking. In today’s era of product design, it is essential to build products with customers in mind, evaluate trade-offs, and craft strategies. These skills are necessary for success in the field.
Industry observation
But a trend I’ve seen in hundreds of interviews is that a candidate is strong in craft but weak in product thinking. Or strong in product thinking, vulnerable, weak in the craft. The designer who is strong in both is often the one we hire.
😰 Too many designers are just focusing on UI (how it looks), some on UX (how it works), but very few focus on why (why it is essential for the users and business).
Today, we will explore the power of product thinking and how designers can train this skill set and mindset to elevate their careers and skills.
Product Thinking
Product thinking doesn’t focus on the output but on the outcome.
Rather than focusing on timelines and dates, we focus on the goal we want to achieve or the job to be done. Because we’re focused on the outcome rather than the output, it is much more difficult to put time constraints around the delivery, at least up front, primarily because we don’t know how to accomplish the goal upfront.
This kind of thinking can be quite the shift, especially for folks who have spent a lot of time focused on projects and project management. Many people are uncomfortable with the uncertainty of not having structured timelines and schedules that they can monitor regularly.
As you peel back the onion, the portfolio will be missing substance. Look for answers to the following questions:
What is the human problem you’re solving?
How do you know it’s a fundamental human problem? (i.e., what research insights or data back it up?)
Why does the business care about this? What business metrics or outcomes might the solution affect?
What was the actual outcome of this work? Was it successful? Did you meet or exceed the business metrics? If not, why?
Do you have a rationale for each design decision, big and small?
If answers to these questions aren’t evident, chances are they are missing one of the hallmark skills of a great designer: Product Thinking. — Garron Engstrom
Why is product thinking important?
It helps you understand the “why” of design
Thinking about products with mobile application UX design can help you create valuable and advantageous features. If you're not clear on the problem, your designer may end up playing a guessing game when it comes to designing features. When product thinking is done right, it creates a domino effect. Once you know why you're building a product, you'll be able to identify your target audience by determining who has the problems you want to solve.
Therefore, you will have the guidance needed to create the right features, and you’ll have a goal (solution to the problem) that can be used to measure the success of any features included with your product.
Full control of your product’s experience
Product thinking simplifies the UX design process by ensuring that designers create with purpose and address real user problems. Every step in the user experience design process must serve a purpose.
Motion design is very trendy today (and will be in 2024). But it would be meaningless if your core design values are mispositioned, and most users today don’t have the patience to sit through a pointless animation display before using an app for its intended purpose. Ultimately, product thinking helps companies:
• Reduce the risk of building an app nobody wants
• Save money by offering the right solutions
• Make smart feature decisions
Elevating Your Product Thinking
Understanding Problems > Gathering Requirements
I tend to avoid using the term "requirement" when discussing problems to be solved because it carries a connotation of rigidity that doesn't work for modern product development. The way it has been traditionally used leads many to believe that it is an order given by the product manager or team, which is why it makes me cringe a little when I hear it.
Gathering requirements has been a common practice for a long time, but if you're only collecting and prioritizing them, you're missing out on most opportunities to create a great product and provide an excellent experience.
Outcomes > Output
It is effortless to become fixated on the end result. The outcome is more comfortable to commit to and easier to quantify. Delivering a feature is a straightforward concept. We commit to a feature, construct it, and then release it. Job done.
However, this type of thinking can yield inadequate experiences or features that no one uses. Instead of just creating features, we must concentrate on the objectives we are trying to accomplish. Building a feature is just one component of achieving those objectives. We must ensure that the feature contributes to the accomplishment of the goal. If the goal is to gain more users, did we achieve that? If not, what should our next step be to achieve our goal?