How to build a shitty product

Everyone wants the recipe to build a great product. But if you take Charlie Munger's advice to "always invert," you might ask: How to build a truly shitty product?

Everyone wants the recipe to build a great product. But if you take Charlie Munger's advice to "always invert," you might ask: How to you build a truly shitty product? One that's confusing, frustrating, hard to understand, and makes you want to throw your computer out the window.

Why Organizations build average product

Every organization sets out with the intent to build a good product. So why do so many of them end up creating something average? The answer lies in the structure and approach of the product team.

A typical product team is composed of product managers, designers, and developers. Product managers (PMs) are the main touchpoint with users; they gather feedback, create specifications, and organize the roadmap. Designers create what they believe is a user-friendly UI/UX based on the PM specs and their interpretation of user needs. Developers, who may include data engineers, backend, frontend, and full-stack specialists, take these specifications implement them into a product.

Why This Approach Fails

Distance from the Customer

Product teams often fall into the trap of designing and building based on assumptions or abstract user personas rather than real user interaction. PMs become gatekeepers of feedback, filtering and interpreting user needs before they ever reach designers or developers. By the time insights get translated into product decisions, they’ve lost touch with what users actually experience. This lack of direct feedback leads to products that don’t solve real problems because the team is too insulated from the people they're building for.

Constraints Over Customer Needs

Too often, product specifications are shaped by internal company constraints—usually engineering limitations—rather than customer needs. As Steve Jobs famously said, "You've got to start with the customer experience and work backwards to the technology." Inverting this process, where the tech defines what’s possible instead of the customer's needs, is a fast track to building something nobody wants. Over-specifying also kills innovation because developers are reduced to coders implementing someone else's vision, without any flexibility to improve or innovate.

Iteration Process is Too Slow

The typical product team works sequentially: PMs specify, designers design, and developers build. This waterfall mentality feels efficient on paper but is inherently rigid. When each step is done in isolation, the process becomes fragile and slow to adapt to new information. The longer each team works in their silo without iteration, the more likely the end product will miss the mark.

Diluted Ownership and Bureaucracy

Who's ultimately responsible for the product's success or failure? PMs? Designers? Developers? Bureaucracy tends to dilute responsibility, and when everything is driven by consensus, mediocrity often follows. Consensus avoids disasters, but it also avoids greatness. True ownership, where someone is accountable for both success and failure, is missing. Some teams get so caught up in Agile, Scrum, or other project management frameworks that they forget the ultimate goal is building something users love. Meetings, standups, and sprint planning become bureaucratic rituals that distract from the real work.

How to Build a Great Product

To build something truly great, you need craftsmen. Product builders who are deeply invested, who care about every detail, and who take responsibility from beginning to end.

Be Close to the Customer

The builder has to be as close as possible to the customer. Talk to them, visit them in person, answer support queries, watch them use the product, and demo it to them. This kind of empathy—truly putting yourself in the customer's shoes—is rare. Builders also need to understand the customer’s underlying problem, not just the feature requests they articulate. Customers may ask for specific features, but often they don't know the best solution; they just know their pain points. The job of a great product builder is to uncover the real issue.

As Paul Graham once said, "Empathy is probably the single most important difference between a good hacker and a great one." You need to understand how little users understand, and if you assume they’ll figure it out on their own, you’re setting yourself up for failure.

Use the Product Yourself

Builders need to use the product they create. That’s why B2C products are often better than B2B ones—builders use what they build and feel the pain of its shortcomings. Most great B2B products, like Vercel or GitHub, are made for developers by developers. It’s much harder to eat your own dog food when building vertical applications for niche users, like lawyers or doctors, but the best craftsmen find a way.

Embrace Single Ownership

The best products come from small, tight-knit teams with clear responsibility. When it’s easy to identify who’s responsible, it’s easier to make great things. Small teams can iterate quickly, and greatness comes through iterations. The boldest approach is to have the same person design, build, and refine the product. With AI coding tools, it's now possible to have a good engineer with taste and empathy that goes from listening to users to implementing a solution, without the need for PMs or designers.

Insane Iteration Speed

Instead of trying to launch a complete, polished product out of the gate, focus on building something small and functional. Once you have that, get it into the hands of users and iterate quickly based on their feedback. The magic happens in iteration, not in perfectionism. Real users will help you refine your ideas and identify what’s actually valuable. The faster you can cycle through feedback loops, the better your product becomes.

Build for Core Users, Not Everyone

Building a delightful product for a few core users is often better than trying to build something for everyone. By focusing on a specific audience, you can deeply understand their needs and create something truly valuable. A product that solves real problems for a small, dedicated group is more likely to gain traction and eventually appeal to a wider audience. When you build for core users, you create passionate advocates who can help drive growth organically.

Simplicity is Key

Paul Graham's "taste" metaphor from Hackers and Painters applies here: you should always strive for good taste in both code and design, removing unnecessary complexity. Simplicity doesn’t mean lacking features; it means that every feature has a purpose, and every line of code serves the user. Good taste in design and code means prioritizing what truly matters to users and avoiding bloat. A simple, elegant product is not only easier to maintain but also more delightful to use. It's also essential to kill features over time—removing what is no longer needed or valuable ensures the product remains focused and effective.

Keep Your Team Small and Focused

You create great products with small teams, but it is also the pitfall of most companies. Big teams introduce layers of complexity, miscommunication, and slow decision-making. Small teams are nimble, communicate better, and move faster. When a team is small, it’s easier to stay aligned on the mission, and everyone has a clear stake in the product’s success. It also prevents diffusion of responsibility—everyone is accountable.

Why Don’t Companies Hire Craftsmen?

This sounds ideal, but it's not the default approach—especially in large companies. Why? Because big companies prefer reducing the standard deviation of outcomes. Only a small percentage of developers can design great software independently, and it’s difficult for management to hire them - often they don't like to work for bureaucratic organizations. Instead of trusting one brilliant craftsman, most companies opt for a system where design is done by committee and developers just implement the designs.

This approach reduces uncertainty. Great results are traded for predictably average ones. If a brilliant craftsman leaves, the company could be in trouble, but if a committee member leaves, it doesn't matter. There’s redundancy in every role.

Take Google—you could fire half the workforce, and it would barely affect product quality. But if you fired someone like Jony Ive from Apple’s small design team, there would be no iPhone. Similarly, look at Telegram Messenger—one of the best digital products ever. They have close to 1 billion active users and yet a small team of just 30 engineers. Pavel Durov takes all the customer-facing decisions while his brother and co-founder, Nikolai, handles decisions regarding infrastructure, cryptography, and backend. They've created amazing results, but if Pavel, Nikolai, or key programmers were to leave, the product would stagnate.

Big companies dampen oscillations; they avoid disaster, but they also miss the high points. And that’s fine, because their goal isn’t to make great products—it's to be slightly better than their competition.

How We Build Product at Fintool

As a reminder, my new startup is called Fintool. We are building Warren Buffett as a service, leveraging large language models (LLMs) to perform the tasks of institutional investors. We follow an approach that emphasizes small teams with clear responsibilities, a lack of rigid roles like product managers, and a relentless focus on speed and iteration.

Small Team with Clear Responsibilities

We keep our team extremely lean, with each member responsible for a specific section of the product. For example, we have one team member focused on data engineering to ingest terabytes of financial documents, another on machine learning for search, retrieval, and LLMs, and a full-stack engineer working on the product interface. By assigning clear ownership to each team member, we ensure accountability and expertise in every aspect of our product. Our accountability is customer-first, with engineers often emailing and interacting directly with customers. This approach means customers know exactly who to blame if something doesn't work.

In-Person Work Only

We believe high-performing teams do their best work and have the most fun in person. Remote work is highly inefficient, requiring the whole team to jump on Zoom meetings, write notes to share information, and lacking serendipity. Serendipity is the lifeblood of startups—one good idea shared spontaneously at the coffee machine can change the destiny of the company. Additionally, we value each other's company too much to spend our days in boring Zoom calls.

No Product Managers

We encourage every craftsman on our team to talk directly with customers, visit them in person, and implement the best solutions. We value discussions and brainstorming, but we minimize meetings to maintain fast iterations and provide high freedom for team members to choose their approach. We follow the "Maker's Schedule," as described by Paul Graham: Makers need long, uninterrupted blocks of time to focus on deep work. A typical maker’s day is structured around productivity and creativity, where interruptions or frequent meetings can be disruptive (I hate meetings.)

Insane Speed

We value speed and push in production every day. One of our core values is to "Release early, release often, and listen to your customers." Speed matters in business, so we push better-than-perfect updates to customers as soon as possible. We believe mastery comes from repeated experiments and learning from mistakes—it's about 10,000 iterations, not 10,000 hours. Another company value is "Clone and improve the best." We don't reinvent the wheel; we enhance proven successesWe are shameless cloners standing on the shoulders of giants. If a design or an existing pattern works well for our use case, we will copy it.

AI First

Using AI tools, like Cursor the AI code editor, is mandatory at Fintool. We believe AI provides a massive productivity advantage. Most people prefer sticking to their old ways of worker but it’s not how we operate. We won't hire or retain team members who aren't AI-first.

Code Over Design

With the speed of AI-assisted front-end coding, we believe that traditional design tools like Figma are becoming less necessary. Anyone can create a nice-looking Figma until they start implementing and discover UX challenges. By leveraging a standard component library like Shadcn UI and using tools that convert prompts directly into interfaces, we can iterate faster and achieve better outcomes. A skilled engineer with good taste can design efficient and visually pleasing interfaces without the need for a designer. It keeps the team smaller and increases the speed.

Our approach at Fintool focuses on leveraging the strengths of a small, empowered team, with each member deeply connected to the product's success. This method allows for rapid iteration, close customer relationships, and the ability to deliver a product that truly meets user needs. However, the main drawbacks are the high dependency on our people. If a key team member is on holiday or leaves the company, progress slows down significantly. We also rely heavily on hiring exceptional individuals—those who are not only talented but also open-minded, like to interact with customers, have a craftsman's mindset and the discipline to work hard. Finding such people is extremely challenging but it’s essentiel for building something truly great. It’s hard but worth it. We are hiring.

“There is no easy way. There is only hard work, late nights, early mornings, practice, rehearsal, repetition, study, sweat, blood, toil, frustration, and discipline.” - Jocko Willink