Product thinking in startups

Story behind-the-scene

In 2021, I switched from working as a product designer in a big company to being part of the startup team - Logto.

Here, I handle both product and design. This new role is a stark departure from my previous experience in a well-structured company with clear processes and collaboration methods. Additionally, I've lost my closest collaborator, a product manager. Consequently, I've had to take on multiple roles, including product, design, research, marketing, and even self-project management.

My team and I frequently find ourselves immersed in the most challenging discussions, often revolving around whether to implement certain product features and define their scope.

In these situations, we all become passionately involved, delivering our opinions, with passion and an opinionated attitude. The viewpoints seem like a concoction generated by a complex machine—unlike written down in the documents, they lack organization and discipline.

This is because "intuition" often emerges before structured expression, resulting in heaps of rambling discussions, leading to philosophical battles.

The motivation behind writing this article is to organize the guiding principles of decision-making. These principles stem from my personal experiences and reflections working in the startup environment, and they're not any kind of silver bullet. I hope to provide inspiration and perspectives for fellow entrepreneurs or those involved in product, engineering, or design.

This article is great for reading if you are in the following situation…

✅ Building a startup team to develop products from 0 to 1, along with GTM (Go-To-Market) strategies, especially for international expansion.

✅ Expanding products from 10 to 100 requires the establishment of a product roadmap.

✅ Product leads or roles with planning responsibilities learn to identify opportunities promptly.

✅ ICs learn to drive new initiatives within large organizations.

This article is NOT great for reading if you are in the following situation…

❌ Ambiguous projects initiated top-down by leads or executives.

❌ Projects distant from business goals aimed at validating individual or independent team impact.

❌ Highly customized product demands primarily focused on large clients.

In most cases, we should be focused

From an absolute standpoint, I even consider keeping focus is common sense, regardless of the organization's size, as resources are limited.

Resources here don't just refer to financial resources, but also time: in terms of time, both startup teams and large corporations are on equal footing.

In most cases, we should focus on creating scalable, essential features that align with our target users' needs and customer personas. The product should be a "pain killer" rather than a "vitamin."

By maintaining focus, it becomes easier and more natural to uphold a clear product value proposition and enhance customer understanding. The product steadily progresses toward its vision, gradually expanding the problem space it addresses in a healthy way, promoting organic growth.

We don't have to solve every problem; we should maintain our perspective and be courageous enough to say no.

So, let me write about different types of "signals" for whether "this feature is worth developing."

Surface-level signals

This concept, "surface-level signals," represents shallow signals that can serve as references but still have a long way to go before making decisions.

Competitors have implemented this feature

While I recently enjoy studying political science, making comparisons is a method akin to political analysis, aiming to gain "possibilities." Having this broader perspective can offer insights, so, in our current context, it's meaningful to study various products.

However, if we overly rely on competitor analysis, it tends to lead to product decisions lacking strategic thinking. It's essential to consider why a competitor hasn't implemented a feature – does it not align with their values, target users, strategic priorities, or resources?

1. Doesn't align with their values
2. Doesn't align with their target user
3. Limited company resources, and there are a lot of legacies
4. Doesn't align with their strategic priorities
5. Of course, don't be afraid to entertain the possibility: Did we overthink it?

So, competitor analysis should provide insights rather than absolute decision-making. It's just part of the information-gathering process for making decisions.

Using logical and subjective scenario deductions

Product folks who are adept at understanding user perspectives and using scenario deduction can rapidly verify or discover new scenarios. However, this is only a hypothesis and requires further work in a real-world go-to-market environment.

While deducing plausible scenarios is valuable, relying solely on this approach can lead to creating an "all-in-one" or cumbersome product before achieving product-market fit, making subsequent iterations and adjustments challenging.

A simple analogy is treating each deduced user scenario as a 0-1 startup project, considering mini go-to-market strategies, bringing marketing perspectives, and asking hard questions. This multidimensional assessment goes beyond user needs and experience.

High-frequency user feedback

Frequently, high-frequency user feedback becomes a guiding principle for feature development and product design. However, this guiding principle can be a trap sometimes. As I grow and working more projects, I establish this kind of framework to tackle and deal with user feedback,

1. Define the problem and crazily and repeatedly reframe it

   This process will involve a lot of deliberation, back and forth, and debates, requiring some time and effort. Don't think that this process is meaningless, because through the discussions, it will diverge and uncover some "underlying iceberg" issues. My team and I used to easily argue endlessly about the right and wrong of something and potential solutions, which is not good. Now, we are more in sync in identifying where each of us feels the problems and focusing on problem-solving. This process is highly valuable.

2. Opinionated vs. Un-opinionated

   It’s super necessary to define whether this feature/scenario should go with an opinionated or un-opinionated approach. For example, Notion is an opinionated product; Google Docs is kinda opinionated; Microsoft Word is not opinionated. As a SaaS builder who aims to innovate the old paradigm, it is better to go with the opinionated approach. Opinionated products divide and filter users, and those who agree with them are enthusiastic about expressing their support. It is extremely helpful to help the early-stage product find seed users and create easy-to-comprehend storytelling.

   If you go with an opinionated approach, try to solve the problem with a single solution per scenario. If an alternative solution arises (Solution B for a given Scenario A), consider if Solution A genuinely addresses pain points. If not, let’s revisit Solution A rather than simply introducing another solution.

   Intercom's product principles have inspired this approach: "Building a product that’s opinionated by default but flexible under the hood."

3. Recognize that users might suggest advanced Job-to-be-done

   Some users might propose using a feature intended for Scenario A to solve Scenario B. Identifying these pitfalls is crucial; don't invest excessive energy in unworthy problems.

   The only situation deserving attention is when Solution B indicates a genuine need, not just an alternative to Solution A. This means Solution B addresses a "newly born problem" closely related to the product's vision and mission. This signal is valuable when the company wants to grow further and discover its next phase of significant expansion.

Bad signals

This feature will complicate the product

Avoiding complicating a product isn't about ignoring solving challenging problems, but it's a reminder that reconciling a "complex, all-encompassing" product with a "simple, user-friendly" experience is unrealistic in the real world. If you ignore how everything works together (system thinking) and only focus on fixing fragmented user experience problems, the result is a badly designed product.

Complex products trigger a chain reaction, making self-service difficult and lengthening the time it takes to see value in the product.

Designing tools for businesses (2B) is somewhat philosophical: it involves creating mental models in tandem with users and establishing a structure that can anticipate user behavior. Complexity often arises from inconsistent and unstructured architectures, trying to satisfy demands by piecing together interactions, resulting in products that are "survivalists" rather than delivering excellent user journeys.

Features that make a product complex, from requirement to solution, are all bad signals.

While this might not definitively help you say no, it's a crucial point that demands clear trade-offs.

This feature will harm the product's positioning and storytelling

In other words, creating features that don't align with a product's positioning damages and blurs the product's image. For example, Logto is a developer tool focusing on identity management at this moment. If I say, let’s build a marketing tool feature, this is a bad strategy.

This feature consumes significant resources but is difficult to evaluate and perceive the benefits

This perspective stems from a company or organization’s business objective. I’ve seen lots of activities done in an enterprise or big corporate environment, such as:

1. Establishing a data platform to enhance engineering efficiency.
2. Creating a growth prediction model annually every single year.
3. Attempting a brand change of a mature product.

In a relatively stable operating state, these scenarios are valuable and should be encouraged and supported. Yet, in challenging start-up environments, such projects require significant resources and time to validate value, indicating a commitment to professional pursuit rather than business success. This point underscores a conflict between personal pursuits, career beliefs, and commercial goals.

While initiating projects proactively is admirable, it's also important to recognize that excessive dedication to something might not yield worthwhile returns: wielding my hammer to find nails, then using a ruler to measure how deep my holes are and how big my radius is—this might not be crucial in the grand scheme. In reality, the person hiring me to hammer nails just needs a way to hang a picture, and I don't need to prove how skilled I am at nailing.

Good signals

Alignment with product vision and roadmap

This abstract yet vital point can be concretely assessed: when considering a feature, ask whether users would be significantly disappointed if the product doesn’t have it, potentially causing them to leave. For instance, consider our product Logto's current positioning to solve authentication, authorization, and user/organization management issues. The more closely related a feature is to these aspects, the higher its priority. If Logto lacked a particular feature, how disappointed would our users be? If the answer is yes, it suggests the priority is high and it’s our mission to provide an excellent developer experience to this problem.

Enough validation or clear hypothesis

Silicon Valley often emphasizes user research and opportunity sizing for their practicality and rigor. These two aspects indicate that a feature is worth exploring and developing when they provide positive insights.

"Why not?"

This concept implies the low-hanging fruit that brings a huge amount of joy and benefits effortlessly, making it a part of the product's personality and brand.

This feature represents innovation

Amidst all the analysis, rational thinking is essential, but allowing space for intuition is also crucial. If you're convinced a feature is the future despite lacking rational data or market validation, it's worth exploring.

Other ambiguous features? Keep it in the research and exploration phase.

Other indistinct features, allow them to develop and we can observe the “signals” over time naturally.

Balancing being open-minded and keeping critical thinking in a fast-moving environment

Throughout product development, entrepreneurship, and product job interviews, you might encounter lots of thought-provoking questions, particularly in Silicon Valley, such as the topic I mentioned above, should we build this feature?

While these kinds of questions might not have universal principles, they require thoughtful execution and deliberation in concrete situations. However, breaking down grand and vague questions into tangible answers is a skill that builders refine over their careers and a superpower to build great products.

I hope the provided insights can inspire your approach to product thinking at a startup. In Logto, we highly appreciate building products developer love. We are happy to chat and share our perspectives on similar topics.