“Je n’ai fait celle-ci plus longue que parce que je n’ai pas eu le loisir de la faire plus courte.” -- Blaise Pascal
I made this letter longer because I didn’t have time to make it shorter.

Clarity and conciseness! Of thought, strategy, design, code. It’s a thing of beauty, but also practicality.

Concise clarity comes at the end, forged through initial naivety, confusion, and contradiction. You iterate through numerous tradeoffs and decisions. You know you’ve arrived not through a formula, but through intuition and taste.

Good marriages and relationships aren’t built by reading the manual. Good health isn’t attained by watching exercise videos. Concise clarity isn’t obtained by outsourcing the process to AI. Rather, it’s forged empirically. Compounding, first slowly, then quickly. Starting fast doesn’t mean you’ll finish ahead.

You become a good writer with pen or keyboard in hand. You become a good programmer by striking keys. You become good at business by running one. You practice, you fail, you learn. You eliminate noise until you’re left with the necessary. The result is beauty you feel but can’t quite describe. Not beauty in the aesthetic sense, more like rightness. When a thing is so well-fitted to its purpose that it feels inevitable, like it couldn’t be any other way. Christopher Alexander called it “the quality without a name.” That’s clarity.

LLMs can help. They speed up research, synthesize information, surface ideas. But at the core, they’re statistical next-word generators, best used as copilots. That doesn’t minimize their transformative potential, rather it sharpens our understanding of how to best incorporate them into our lives.

Here are a few things I learned

Don’t let the LLM write for you. Writing isn’t about the outcome; it’s about the thinking process you take to reach it. You can’t separate writing from thinking. To write is to think. Use the LLM to surface information as needed, then do the work of integrating it. Run it through for editing and final tweaks, but only once you’ve reached clarity and “rightness” yourself.

Human connection thrives on quirks, not polish. But LLMs write in “brown.” These days, I can easily spot when someone wholesale outsourced their writing and thinking to AI.

I’m still refining how to best use LLMs to enhance my writing, coding, and problem-solving. Right now, I lean toward making it more manual. I start with a blank page. I don’t want to be immediately influenced. I want to clear my mind first. I write, then ask for editing advice, then read through and decide what to incorporate. It’s been hit or miss on editing, so I don’t see myself moving to “Here’s what I wrote, can you rewrite it?” any time soon.

When coding, I do the same. LLMs are great at bootstrapping a new repo, but that’s when I stop letting it control the keyboard and go back to asking pointed questions, deciding what to incorporate. The results have been mixed. Sometimes it works, other times we iterate through many variations of my prompt without a satisfying result of clarity. But it’s sure an amazing context-aware auto complete of code blocks and sometimes functions.

I find the synthesis abilities of LLMs superb. Whether synthesizing research or explaining a codebase I didn’t write, it does a great job saving time. But I also wonder if skipping the effort to grind through it myself is detrimental to longer-term learning and results. Remember, growth comes slow, then fast :-)

In contrast, generative AI is ambitious. It’s full of energy. It doesn’t get tired. It’s patient. It doesn’t get annoyed. It’s indiscriminate and uncritical. It thrives on more. This is the exact opposite of what drives good design. Good code comes from someone annoyed enough by complexity to simplify it, impatient enough with tedious work to automate it, and lazy enough to eliminate superfluous effort. Annoyance, impatience, and laziness toward the superfluous is a killer creative mixture that drive good design and progress. AI has none of these properties. It feels nothing. It’s just as happy to write 10k lines of code to do something a human would find a way to do in a few hundred. It’s happy rewriting the same program 100 times, without truly understanding what’s happening under the hood. It has no design taste.

I see a reckoning coming. The world is producing a lot more software, but is it good software? Does it solve the problem well? Is it well designed? Is it maintainable and understandable? Can it be easily extended? Does it have taste?

GenAI tools are exciting. I use them daily. Our teams are building AI-enhanced capabilities that would have been impossible just a few years ago. There’s amazing energy in the air, and it feels like the mid-90s and the birth of the web again. The possibilities are broad and deep. But I’m worried about the blind spots and blind enthusiasm I’m seeing in the industry when it comes to outsourcing human reason, creativity, thinking, and taste. The very things we see as limitations, like our impatience with bad code, our annoyance at complexity, and our laziness toward the superfluous, aren’t bugs. They’re features.

P.S. This post was not written by AI, but the image was generated by Sora :-)

Finding Product-Market Fit by Focusing on the Somewhat Disappointed Users

When building something new, finding product-market fit (PMF) should be your primary focus. All decisions should center on learning and iterating. Rahul Vohra from Superhuman developed a systematic approach to measure and optimize for PMF, which I find fascinating.

In summary, Vohra's approach works like this:

1. Survey current users with a simple question: "How would you feel if you could no longer use the product?" with possible answers being "Very Disappointed," "Somewhat Disappointed," or "Not Disappointed."

2. Focus on the 'Somewhat Disappointed' users rather than the other two groups. Users who would be 'Not Disappointed' if your product disappeared are likely poor fits for your offering or are too far gone. Meanwhile, users who would be 'Very Disappointed' without your product are already satisfied enthusiasts. The middle 'Somewhat Disappointed' segment represents your greatest opportunity - they see value in your product but encounter obstacles preventing full adoption.

3. Research and analyze the "Somewhat Disappointed" segment to understand how to convert them into enthusiastic supporters.

4. Build your roadmap to address what holds the middle segment “Somewhat Disappointed” group back and turn them into "the “Very Disappointed” group.

5. Rinse and repeat

While algorithmically achieving PMF isn't guaranteed, this systematic approach helps segment customers and focus your research effectively. I recommend complementing this with Jobs To Be Done (JTBD) interviews to better understand customer behaviors, motivations, and tradeoffs of the middle segment.

Solution Deepening versus Market Widening

This concept, also from Rahul Vohra, distinguishes between two types of capability development:

• Solution Deepening: Improving existing capabilities to further delight current customers

• Market Widening: Developing capabilities to attract new market segments and fulfill additional jobs-to-be-done

The key is to consciously clarify which of the two strategies you're pursuing and which capabilies help you get there.

Kano Model

Another model I turn to when I try to think through product strategy and priorities, is the Kano model. The Kano Model helps prioritize features based on customer satisfaction and needs:

• Must-Have Features (Baseline): These are basic market expectations that customers take for granted when present but cause extreme dissatisfaction when absent.

• One-Dimensional Features (Wants): These features have a linear relationship between implementation and satisfaction—better implementation leads to greater satisfaction, while poor implementation decreases satisfaction.

• Delight/Excitement Features: These unexpected features greatly please customers when present. They create disproportionate satisfaction and delight without causing dissatisfaction when absent.

An important aspect of the Kano Model is that as markets mature, consumer expectations evolve, and technology advances, features migrate downward: Delight → Wants → Baseline. As this happens, you must continually discover and deliver new Delight features while enhancing Wants features. Using this classification alongside an understanding of consumer motivations can significantly improve roadmap prioritization.

JTBD Forces of Progress

One of the most powerful models in the Jobs To Be Done theory comes from Bob Moesta: The Forces of Progress. This model recognizes that when consumers seek a solution and make choices, four forces either help or hinder their progress toward finding a solution:

Forces That Aid Progress:

• Push of the Current Situation: When customers experience issues with their existing solution, eventually creating enough discomfort to push them toward seeking something new.

• Pull of the New Solution: As customers evaluate potential solutions, they assess how capabilities align with their desired outcomes and imagine a better future.

Forces That Hinder Progress:

• Anxiety of the New Solution: Concerns about the new solution working properly, migration challenges, training requirements, and other uncertainties.

• Habit of the Present/Inertia: The comfort, familiarity, and established processes with the current solution, which can be difficult and politically sensitive to change.

Many product teams focus primarily on the Push and Pull forces—identifying problems and building aligned solutions. However, they often struggle to make market headway because they neglect the two hindering forces.

Example: House Hunting

Consider someone looking for a new house:

• Push: "Our current house is too small since we had another child. We want a more open layout for better family interactions."

• Pull: "The houses we've looked at are much larger and have beautiful open floor plans."

• Anxiety: "Many homes in our area are 100 years old and could be money pits. Will we find a comparable backyard? Will the neighbors be friendly?"

• Habit/Inertia: "We love our street, location, and current neighbors. Maybe renovating our existing home would be better than moving."

Modeling customer behavior around these forces can help develop better features and roadmaps that not only pull more customers with struggles but also help overcome anxiety and inertia. Consider prioritizing features specifically designed to address customers' change anxiety or habit of the present.

Conclusion

Strategy and roadmapping remain creative endeavors, but using these mental models can significantly improve decision-making. They provide structured ways to think about customer needs, market positioning, and adoption barriers, ultimately leading to more successful products.

What other models or methods do you use to help develop a better strategy and roadmap?

I typically prefer integrated experiences, as they are usually more polished, more cohesive, and have a premium feel. Apple represents the gold standard here. But there are many other examples. Tesla owners praise the end to end experience across sales channels, infotainment, and service as the reason they bought and remain loyal customers, even as competition catch up technologically. When companies genuinely commit to and integrated experience and end-to-end quality, magic happens.

However, being a market incumbent changes incentives. As Apple has grown enormous and achieved a near-monopoly position in certain segments, a concerning portion of their profits now comes from rent-seeking rather than innovation. With limited competition and a strong hold on existing customers, their drive to innovate weakens.

Google and Android present a counterpoint. Initially, its modular approach created fragmentation that frustrated customers - I remember trying and quickly abandoning Android years ago after spending too much time configuring my phone for a seamless experience, rather than using it.

But things have evolved. Google's Pixel phones now deliver an Apple-like integrated experience across Google products. Meanwhile, Android OS remains open, allowing Samsung, Motorola and others to compete. This gives customers options and forces Google to keep innovating and polishing their integrated experience. If Pixel falters, users can switch - creating healthy competitive paranoia and innovation pressure.

The sweet spot between modular vs. integrated approaches may lie somewhere in between. A company offering an exceptional vertically integrated experience, with enough competitive pressure from the modular players to remain hungry.

While we can attempt to model complex systems, their behavior is often stochastic rather than precisely predictable. Examples of complex systems include biological systems like the human body, social systems, financial markets, and the one we’ll focus on here: distributed software.

There are many proven practices that help improve software quality — including test-driven development, good test coverage, continuous integration, code reviews, frequent small deployments, static analysis tools, and pre-release checklists or risk assessments. But there is a saying in the software circles: "All bugs have one thing in common — they all passed the tests."

Distributed software systems are inherently complex, exhibiting emergent behaviors and a high degree of nondeterminism. While rigorous engineering practices I described earlier are essential, they are not sufficient to fully capture the vast space of possible interactions and failure modes. Is there a better way to think about quality within the complex software systems?

This reminds me of Taguchi’s Robust Engineering methods, which focus on making systems less sensitive to variations in noise factors — and therefore more reliable and consistent. Bob Moesta, who worked with Taguchi in the 90s, introduced me to these ideas some time ago. There are three things I’m exploring to see how they can fit into our software development process.

P-Diagrams are a useful way to model a system by breaking it down into signal, control, and noise factors. This helps clarify what we can directly control versus what we can’t — the noise factors. In some cases, we can design the system to take control of a noise factor. In others, we need to build the system to tolerate the variations.

Once you’ve modeled the system properties, you can start designing and testing for robustness. Techniques like property-based testing and chaos engineering are built for this. Most modern languages now have frameworks that support fuzzing and property-based testing. Python’s Hypothesis is a popular property-based testing framework. On the chaos engineering side, tools like Chaos Mesh and Chaos Monkey help simulate failures and unpredictable conditions in distributed systems.

Taguchi also introduced Design of Experiments, a method for efficiently exploring interaction between control and noise factors. I’m still wrapping my head around how to utilize this within a software development process, but I’d love to understand how to use these methods for understanding and tuning complex system design.

We’re lucky in software — we have a growing set of methods and tools to help us design, test, and build for robustness. I’d love to see more teams use them.

Over the next few months, I’m planning to explore these ideas further and look for ways to apply them in the clinical trials software space — where building more robust systems can directly support better drug development and improve patient outcomes.

But here’s the problem: these tools often lack what makers actually need. Makers benefit from tools that support problem-solving, shaping the work, evaluating tradeoffs, and iterating toward a solution. In other words, they benefit from tools that help them do the work, not just track and report on it.

The reality is that few tools effectively serve both groups. Since managers usually control the purchasing decision, tools tend to skew in their favor—leaving makers to deal with software and processes that adds little value to their day to day. Here are a few examples.

Many roadmapping tools (like Productboard, Roadmunk, Aha!) excel at tracking and reporting. If you input your data, configure the right fields, and tag items properly, you can generate detailed reports for executive planning and status updates. But the outcomes product managers seek isn’t just about reporting — it’s about figuring out what creates value for customers and how to turn that into value for the company. The best tools help synthesize customer insights, frame problems, and shape the work, see contrast and make tradeoffs between various alternate paths.

Most roadmapping tools fall short here. That’s why so many effective product managers turn to digital whiteboards like Miro or FigJam. These tools aren’t perfect, but they’re flexible, intuitive, and designed to facilitate thinking, iteration, and collaboration, rather than just documentation.

Same goes for project management tools like Jira, Monday, Asana, etc. From what I’ve seen most ticketing and tracking tools tend to be almost universally disliked by engineers. To them, these tools feel like overhead, something that’s more about tracking tasks than facilitating problem-solving or forging solutions. A good tool should help teams diverge in their thinking and then converge on a solution, but most of these tools don’t support that process and in many cases get in the way.

This is why we need to be more thoughtful in how we choose our tools. The emphasis should be on serving the makers and helping facilitate their work — not just solving for managerial struggles. As someone who’s a manager but also, first and foremost, a maker, I’ve felt the pain on both sides. Hopefully, over the next few months, as we take a look at our process and tools and refine them, I’ll write more on this topic.

“Welcome back, Mr. Sterin. On your desk, you’ll find some free pastries. Thank you for being a loyal customer. If you have any questions or issues, please don’t hesitate to contact me personally. ” — Signed by the hotel manager. The letter was warm. It made me feel appreciated and good. The free pastries were devoured immediately, as I was really hungry from travel.

Over the next few months, I got the same warm welcome, and it felt good each time. I looked forward to walking into the hotel and getting the treats. But that changed on my last trip.

During my Christmas break, as I assessed the year, I noticed I traveled much more frequently than usual. Although I love spending time with my colleagues, I was reflecting on the time away from family. Was I overdoing it? Was I missing out on important time at home?

During my first trip to NY in 2024, I walked into the hotel and got the same warm welcome. But this time, I didn’t quite register the same way. I read the note once more, “Welcome back, Mr. Sterin…,” but this time, instead of feeling good, I got sentimental. It was a reminder of the guilt I felt of being away too much. It made me think about whether all the travel was necessary. Can I cut it down? It made me rethink the necessity of some of my future trips.

The same loyalty feature that made me feel welcome just a month ago now evoked a feeling of guilt and sadness. It made the hotel feel like a second home I never wanted.

This made me think of “context”. We always think of features in terms of solving problems that customers have, but Bob Moesta, through the lens of JTBD, has always taught me to look a level deeper. To think about the context in which struggle occurs. What might seem like a solution to a struggle in one situation might have the opposite effect in another. Bob calls this “Context switching around a feature set,” and Taguchi would call that robustness. At the crux, it’s evaluating solutions and their tradeoff in a particular context, digging beyond the surface of a problem.

Subscribe now

Yesterday, I talked to someone who was frustrated because their company talks about using agile but follows a more waterfall approach to product development. They have long-term roadmaps and extensive backlogs and use Gantt charts to track complex project delivery dates. There is no true iteration. Why do we all want to be more agile but end up using practices that go against those principles?

Before I discuss what hinders our agility, let's quickly go over the fundamental idea behind agile. The core principle of agility, the rises above the others, is "Responding to change over following a plan." As the saying goes, “No plan survives first contact with the customer.” Plans need to change in response to the market and customer feedback. To be agile, we must validate our ideas quickly, deliver working software regularly, learn from customer and market interactions, and adapt.

So now that we understand the core principles of agility, why do so many companies want to be agile, talk the talk, but fail to iterate and deliver continuously?

Interdependence

Interdependence is the crux of most complexity and mayhem. When teams lack autonomy, and the organizational structure and system architecture don't consider this (as per Conway's Law), the result is a need for armies of project managers and numerous status and alignment meetings to manage the web of dependencies.

So what’s the solution? Reduce interdependence. Work hard on rethinking the architecture. Implement better communication contracts and boundaries across teams and services. This won’t happen overnight, but the folks from Team Topologies have created a good model that can help move towards reducing interdependence.

As you progress in reducing interdependence, you’ll move more towards the agile spectrum of product development, which is about iterative learning and delivery.

Subscribe now

We often hear, “Customers know best.” They know their struggles, desired outcomes, and context. But they are usually bad at designing a solution. It’s up to us to uncover the struggles and context, extract the causal mechanisms, organize the dots, and turn the irrational into the rational. It’s up to us to design an opinionated solution.

Product isn’t about solving a problem in every way; it’s about solving a problem in a way. It’s a pattern language we build for a particular set of problems and their context.

Don’t outsource the job of designing the product, to your customers.

If you've read Taleb's books, you've encountered the concept of fat-tailed distribution. Taleb highlights how we often underestimate the likelihood of “rare” events. Yet, with fat-tailed distributions, these “rare” events become almost inevitable given a long enough time.

It’s important to iterate in increments of “smaller projects” by capping the time investment. Various principles in "Shape Up" help to effectively manage the challenges and uncertainties of real-world projects. This is done through:

1. Setting an appetite, where we explicitly cap the risk and prevent runaway projects

2. Shaping, where the team tries to uncover risks and uncertainties. They then make tradeoffs and find a solution within the appetite.

3. Hill charts (uphill/downhill work) help the team manage risk, tradeoffs, and interdependence as early as possible vs. linearly working on and completing “tasks.”

Ryan Singer was visiting Detroit a few weeks ago, and during our conversation, he helped me gain clarity around the different types of work.

Many organizations tend to lump all tasks together, leading to a vast, undifferentiated pile known as the Backlog. Though teams may prioritize or categorize these tasks, the essence remains the same, much like rearranging eggs in a carton doesn’t change the fact that it’s still a carton of eggs. This approach often blurs the distinction between strategic initiatives and a whirlwind of other tasks.

It’s super helpful to classify the types of work that exist on a product team.

1. Strategic Work - These projects contribute to company and product growth and add considerable value. This can encompass adding or improving features or considerable refactoring aimed at decreasing product lead times. These tasks are integral to the product's vision and the creation of value.

2. Small Tasks - Sometimes, you have to sweat the small stuff, as long as it doesn’t get in the way of making real progress. These minor tasks could involve fixing minor problems that are bothersome to customers or us, refactoring small segments of the codebase, addressing non-critical bugs, or making slight enhancements to the user interface. These are tasks we want to complete but they don’t take priority over strategic tasks.

3. Urgent Tasks - Certain circumstances demand immediate attention. Servers go down, critical bugs pop up, or something fails in the production environment due to an oversight in testing. These tasks require immediate attention, often necessitating other work to be put on hold.

This simple model can help us in two ways. First, it’s very helpful to classify your work to see where time and effort are allocated. If your time is primarily consumed by dealing with urgent tasks, then this suggests a need for improved stability and quality. Conversely, if you are overly occupied with small tasks, this could indicate a deficiency in strategic thinking and planning. Ideally, a majority of your time should be devoted to strategic work.

Second, the model is great in helping us build a better process for executing all three. Shape Up is a fantastic framework for strategic product work. It can also be used for planning and executing small tasks in batches or during cooldowns. But it says little about urgent tasks. Here is a process that we’re experimenting with.

We use Shape Up for strategic work, with a list of framed bets. In our betting sessions, we select which bets to shape for the next cycle based on our goals, roadmap, interdependence, resources, etc.

For small tasks and any urgent matters, we utilize a Kanban board. These are tasks we want to tackle but aren't strategic.

We assess our capacity and appetite for the smaller tasks during cycle planning. If we don’t have enough strategic work to keep the team busy, or there are enough small tasks that have become important, we create a small batch project and execute it as planned project work.

Teams with regular urgent tasks should reserve capacity for them. This ensures those working on strategic projects remain focused. This responsibility can rotate among members. During the cycle, such teams can address small tasks on the Kanban board and shift to urgent matters as they arise. This work is unplanned, but it can still allow for progress to be made, while also ensuring strategic work doesn’t become the victim of the “urgent”.

For most people, forgetting is a cause of anxiety. But forgetting is the brain’s routine for optimizing storage, consolidating thoughts, and building room for new ideas. A couple of weeks ago, I came across a book, Forgetting by Scott A. Small, which covers this topic in detail.

The book first goes over the process of forming and retrieving long-term memories. How the hippocampus helps consolidate the memories, and how other sensory regions help strengthen or weaken these connections. It explores dendritic spines, which grow and shrink during consolidation, and the recently discovered molecular process dedicated to forgetting.

The rest of the book connects the benefits of forgetting for creativity, innovation, fear, mental disorders, and optimal decision-making. To generate novel ideas, connect disparate concepts, think abstractly, and make optimal decisions, one has to forget. Forgetting is not a process of completely erasing memories but rather making them less detailed. It’s a process of generalization. Only then can we see patterns otherwise lost in the mayhem of detail.

P.S. In ML, learning algorithms are a way of generalizing knowledge. This concept is somewhat analogous to memory consolidation, where lack of forgetting is known as overfitting.

These patterns are present in almost all creative work. Figuring things out phase requires the skills to tame the optionality beast. It’s a skill we struggle with most and have to select for on a team.

Many companies make the mistake of thinking that having someone senior on the team would aid this. In my decades of experience interviewing engineers, I found that seniority rarely directly correlates with the ability to operate in a large space of optionality. People with 10+ years of experience, who can deeply discuss various complex algorithms, time and space complexity, have deep experience with the technology we’re using, and have developed very sophisticated software in the past, got stuck at trivial tasks with too many possibilities. Asking them to create a simple reverse proxy server using a language of their choice and without using an existing library, forced them into rabbit holes, unable to evaluate tradeoffs and make rapid decisions. They didn’t get stuck during algorithm implementation; it was much earlier, during the uphill discovery phase.

Many engineers, regardless of seniority, spend most of their careers operating within narrow guardrails. This is especially prevalent in large companies, where engineers rarely build the muscle required to produce in environments with little or no constraints. But to run productive autonomous product teams, you have to select and train for this skill. You’ll need at least one person on each team who can help the team go uphill and operate in a large space of optionality.

This notion parallels well with business operations. Many companies seem to be perpetually synchronizing, as evidenced by incessant meetings or practices like ensemble programming, but they miss a huge opportunity to do work in parallel. Structuring teams and projects to remove interdependencies and periodic integrations is a small price to pay for the productivity gains realized when each team and person (thread) can do as much work as possible on their own.

Just as most programmers had to learn new skills and gain experience to become good at parallel programming, asynchronous work environments require a new way of thinking and new skills.

First, you have to structure your teams and work in a way that allows more autonomy. In large organizations, you can structure teams to reflect the various business subdomains (bounded contexts). In smaller organizations, multiple teams working on one product and codebase can be effective, but you have to structure parallel work to reduce interdependencies. For example, you can prioritize two orthogonal features over features that require significant changes within the same parts of the code.

Second, and one of the most critical skills, is you have to learn to communicate well in long written form. You have to favor clear, concise, well-thought-out writing over short and ambiguous blurts prevalent in meetings and tools like Slack.

Synchronous work is expensive and inefficient. The move to working more asynchronously isn’t easy, just as it’s not always easy to parallelize a software process. But it’s well worth it, and the result will be a more resilient and effective organization.

A tradeoff is a balance achieved between two outcomes through compromise. You’re not really making a tradeoff unless you’re losing something in the process.

If I live in LA, should I trade a longer commute for a bigger and cheaper house outside of LA, or should I pay more to shorten my commute and have easy access to city amenities? Should I spend another $400 to upgrade to more cores on my laptop and will the benefit outweigh the expense? We’re used to making such economic tradeoffs in our personal lives, but I’ve found that this intuition is often missing in the world of product development.

How does one build intuition about making sensible economic tradeoffs in product development?

The economics of products

Reinertsen asserts that the activity of product development should optimize for the Gross Profit of a company. Removing for a minute any non-profit or philanthropic motives, the economic desired outcome of building a product is to generate a profit.

You can use the measures of profit to guide your tradeoff decisions. At the high level of strategy and features, it’s relatively easy to estimate profit. At the lower levels of implementation, it’s harder to correlate profit directly to activities, so we need good proxy variables.

Cost of delay

Cost of delay refers to the economic value of bringing a product or feature to market faster. What is the cost of 2 more months of developing this feature? How much time should we invest in a feature to reduce the cost of delay and maximize its ROI? Understanding the demand and supply side economics helps prioritize the work.

Lead times

Lead time refers to the time from conception to release of a product or feature. Lead time needs to incorporate all of the activities needed to bring a feature to market, including testing, deploying, bureaucratic approval processes, etc. Reducing lead times helps reduce the cost of delay.

There are two ways to optimize this. First, it’s critical to truly understand the problem you’re solving on the demand side, which in turn helps design an optimal solution and set scope boundaries. Scope can be managed by setting explicit time constraints for a feature’s lead time (more on that later). Second, it’s important to optimize and automate the DevOps process, which includes the development, testing, deployment, and infrastructure management.

Risk

We need to be able to quantify risk if we’re going balance it with reducing lead times. There are numerous risks like: the risk of having the wrong assumptions; the risk of introducing a quality defect and upsetting the customers; the risk of failure or cost overruns due to variability.

We can invest a lot of time in derisking, but we need to know at which point this investment outweighs the benefits. We pay for derisking with longer lead times.

Some industries, like SaaS software products, have higher risk tolerance. As my conversation with Justin illustrated, it’s important to acknowledge the different risk tolerances of different industries:

User acquisition

Acquiring users is a proxy for profits and should be used during the decision making process. Tradeoffs between prioritization, scope, and design can focus on its effects on user acquisition. Obviously, we can’t precisely predict how many users we’ll acquire, but if we understand the problem we’re solving, we should have some idea of the market. We should be asking questions like “Will cutting scope from this feature still solve the problem?” and “How will it effect user acquisition?”

User retention

Customer churn is a part of any product and new customer acquisition is frequently more costly than retention. In many cases, investing in keeping your current users happy is more profitable than trying to acquire new users.

Many companies focus on user acquisition as a priority over anything else, but frequently there are more opportunities for increased profits through current user retention. Understanding the profitability of new customer acquisition vs. existing customer retention can help you make better tradeoffs.

Forcing tradeoffs through time boxing

A hard deadline is a great tool for forcing tradeoff decisions. Without a time constraint, there is little incentive for compromise.

Ryan Singer’s book Shape Up describes this notion as “appetite”. How much time does it make sense to spend to deliver a satisfactory solution? Deciding on the upper limit of time, will force you into thinking of economic tradeoffs and deciding what’s crucial.

Time boxing is not about estimating how long it will take to deliver the solution. It’s about finding the balance between the the economics of the demand side (problem) and the time and money investment on the supply side (solution).

Economics of features

Let’s say we’ve uncovered a demand side struggle and are going to design and implement a feature. Before we go to deep into solution design, we should decide on how much time we’re willing to invest, which will in turn force design and scope tradeoffs.

While deciding on how much we are willing to invest in a feature, we can ask questions about its effects on user acquisition and retention. We can think about the costs of delay. We can think about risk in terms of quality and unknowns.

In some cases, cost of delay will drive the tradeoffs and make us cut scope to go to market faster. In other cases, minimizing risk might be the right call. In my experience, mistakes are more tolerable in SaaS software products than they are in industries with complex distribution models or mission critical products. Therefore, the cost of delay will most likely be the driving force of many tradeoff decisions for SaaS products.

But what about refactoring?

Feature tradeoffs are typically easier to reason about due to the ability to directly link its benefits to potential economic upsides. But what about tasks more technical in nature? Things that the user will never see directly? Refactoring comes to mind as a frequently planned activity, but teams can rarely explain a direct economic benefit. Is this refactoring worth pursuing?

Refactoring economics are typically centered around optimizing lead time and reducing risk. Sure, this part of the system causes longer lead times due to a bad design, but if we only touch it once a year for bug fixes or small changes, investing a 4-week cycle in refactoring probably doesn’t make economic sense. On the other hand, if it’s a frequently touched part of the system, which has a consistent effect on lead times and risk, investing in refactoring might be the most economically savvy decision, especially if we can measure its impact.

Conclusion

Understanding the economic variables of your product and how they relate to each other will help you make better tradeoffs. Making them a part of your decision checklist will help you prioritize work and better invest resources.

A couple of months ago I stumbled on something which stopped me in my tracks. I realized that the way I consume and retain information and form ideas was not efficient. Innovative ideas are typically amalgamations of concepts accumulated over time. But my note-taking and information retention system was fundamentally broken. What could I have accomplished if I had an effective way of retaining every important idea?

The problem I encountered

I was writing a blog post about B2B product sales. I had some immediate thoughts of what I wanted to cover, but I needed to gather materials that would help me write the post. My intuition about B2B sales didn’t form overnight — it’s been in the making for over 10 years. It was shaped by experiences, study of various concepts in the psychology of decision making and choice, business, economics, numerous concepts from the theory of Jobs To Be Done, etc. How would I even begin to recall and summarize all the empirical and academic information I’ve encountered over the decade? I could probably recall a handful of concepts that relate to the subject, but to gather everything that explicitly and implicitly shaped my thinking would be daunting and practically impossible. What’s even less possible is trying to discover relationships between seemingly discrete ideas that might be related to the topic I was currently writing about.

I wrote a short blog post, but it left a lot to be desired. I didn’t have weeks or months to spend on gathering all the data, and I was even intimidated by having to revisit ideas I haven’t touched in years.

Imagine a world where you can easily tap into most of the ideas that shaped your mind on a particular topic and understand the relationships between those ideas. Imagine being able to replay the story of how you shaped your thoughts on a topic. Imagine being confident that you have recalled all the information which might be related to your project.

What’s wrong with note-taking

In order to retain information, people take notes. There is a seemingly endless supply of apps that people use to take and organize notes. But they rarely if ever revisit them, especially outside of the current project.

Most current notes taking systems are transient and disconnected. We don’t have a way to connect and network thoughts. The creative process is messy and dependent on creating relationships between discrete ideas over time.

We consume information daily, deliberately or not. A lot of information we consume has little relevance outside of transient entertainment value. To be honest, most of the information I come across daily, I wish I could erase from my brain. The knowledge which we deliberately acquire in the process of working on a project, reading a book, writing a blog post, doing research, etc… is what we want to retain. We want to be able to tap into that knowledge at a later point in time. We want this knowledge to affect our future thoughts and ideas.

In order to tap into the knowledge we acquired at the time when we need it, not only do we need a way to store it, but we need to have an easy, intuitive way to discover and retrieve it all over again.

Zettelkasten

During his prolific research career, Niklas Luhmann published more than 70 books and 400 scholarly articles. Not only is his productivity admirable by today’s standards, but he accomplished all of this without most of the modern productivity tools we use today. When asked what he attributed such productivity to, Luhmann gave credit not to his wit and amazing memory, but rather to the note-taking system he developed early in his career.

Luhmann named this system Zettelkasten, which is German for a “note box.” The two crucial elements of this system are the note labeling system and the relationships between notes.

He adopted a hierarchical numbering system, which allowed him to not worry about where each note goes. To insert a note, he could in theory add it to the end of the “note box”. Say you have 200 notes in the box labeled 1 through 200, the next note would be labeled as 201. Because some notes expand on existing ideas in the note box, if, say, you want to add more information to the topic discussed in note 155, you’d simply make the next note nested and number it 155.1. In theory, this nesting is limitless, as you can then expand on 155.1 using two notes 155.1.1 and 155.1.2.

The hierarchy is important, especially given that Luhmann wrote all notes on index cards. Due to the space limitations, to expand on previous ideas, you’d have to create new index cards vs. edit the current one. The hierarchy also allowed him to see how his ideas formed over time.

The second, and most critical, element of his system is the interconnection of notes. Whenever he would connect two ideas, he’d reference these ideas in his notes, by using the immutable numerical label assigned to each card (i.e. 155.1). The idea wasn’t to relate this card to every relatable note in the note box, but rather to relate it to something. Just a couple of relationships on each card exponentially increase the related content as you navigate the degrees of separation.

For example, I retrieve a note with a particular idea, which relates to two notes, which themselves relate to two more. I now have 7 notes which are all possibly related to the idea in the original note at hand. There are huge benefits to this. One is you’re not forced into figuring out every possible related concept at the time of note-taking. Two, it allows you to find the spontaneous indirect relationships which form over time.

Obviously, I’m missing a few details about Zettelkasten, but in my opinion, the two elements above are the core of the system.

Zettelkasten 2.0

Can we take the core parts of Zettelkasten and make them even better given today’s technology choices? First, let’s define what the core parts of a good personal knowledge base are.

Quick unobtrusive entry

Quick unobtrusive way to take notes, anytime, and anyplace. You can’t build a knowledge base if you can’t easily write down your thoughts and ideas when they arise. These notes don’t have to be fully refined, rather you just need a way of capturing them in the moment.

Bi-directional linking

Just like Wikipedia, your knowledge base should allow you to go down the exploration rabbit hole. You pick a topic, and you can follow links to discover the related ideas which you have come across at different times of your life. This allows you to find all linkages when you need them and even infer relationships you didn’t know existed. Your knowledge base gives you instantaneous ability to amalgamate the ideas you form over time.

Not only are you able to follow links and discover relationships, you can also look backward through backlinks. Backlinks allow you to look at a topic and see how many other notes reference it. This is important when say, you want to reference “Confirmation Bias” in your current project. Looking at all other notes which reference this topic would allow you to resurface ideas you’ve come across but have forgotten.

Bibliography

Ideas are formed by consuming information over time. Referencing this information in your notes is important, as you might want to return to the source at a later time to see if your understanding evolved or if there is something you missed.

Instead of cluttering your notes with repetitive bibliographical references, you should keep them separate and reference them in your notes.

A powerful way to explore

The reason you’re creating the knowledge base is to actually use it. This means you need a way to discover the information you need at the time you need it. Today’s technology allows for full-text contextual search.

Trying to recall all possible related concepts and ideas while you’re forming your thought is impossible, courtesy of your human brain. Contextual search can also allow you to discover implicit relationships.

Portability for life

Your personal knowledge base is your life’s work. You can’t depend on some proprietary software to be around forever. You need to make sure that notes remain accessible in formats that would allow you to easily port them to other products and workflows. This means that notes should be in plain text formats (i.e. Markdown). They should be accessible on a filesystem as files, not in a proprietary database format.

Offline support

Not only should you be able to work offline in case your internet connection is spotty or unavailable, but the best way to do deep thoughtful work is to sometimes disconnect on purpose. Web applications have poor support for offline work. I believe native applications are much better in this regard. Not only do they work offline, but they are often faster and more polished.

Versioning

It’s useful to be able to track how your thoughts and ideas evolve. Programmers use version control systems to allow them to look back in time to see how the application and code evolved over time. Just as any application, thoughts and ideas evolve over time and you want a way to reconstruct your evolution chronologically.

Taking notes purposefully

Given the ideas of Zettelkasten what if any changes are needed to your note-taking practices.

1. It doesn’t matter where you take transient notes. If you’re reading a book, you can highlight, underline, and make notes in the marginalia. You can use a pocket-sized notebook and take handwritten notes, or use a digital note-taking system. Just make sure there is little impediment to quickly taking notes anywhere.

2. Review and integrate your transient notes frequently. Don’t allow too much time to pass between taking a transient note and before you decide if and how it fits into your Zettelkasten. As the name implies, transient notes are quickly forgotten. If you’re taking notes while reading a book, reviewing and synthesizing your notes every chapter is something that works for me.

3. Takes notes with a purpose. Ask yourself these questions:
   - Is this something I want to retain?
   - When will I want to recall it?
   - How does it relate to other ideas in my current “note box”?

4. Refine ideas in your notes by keeping track of how your thoughts evolve chronologically.

Conclusion

I’m currently building and refining a system to fit my workflow and working on building my Zettelkasten. There are numerous tools out there that attempt to help implement the ideas I discussed, but in some way or another, they fall short. I’ll probably do a review of some of these tools in the near future, but for now, I’m focusing on refining my process and I’m purposefully staying away from the rigidity that some of these products introduce.

When I first learned about Jobs To Be Done from Bob Moesta and Chris Spiek, one of the core concepts that stuck with me was the emotional and social aspect of why people buy and consume products. Looking through this lens, I was no longer constrained by just functional innovation. Rather, I could dig much deeper, which in turn opened the door to a broader set of possible solutions.

See, unless you’re buying a repeat product, all other product purchases are what we call a switch. To “hire” a new product, you have to first “fire” what you’re currently using or doing. This switch is very emotional, packed with anxiety, habits, and social considerations.

For example, we all have experiences with TODO applications. But why do most people keep firing their existing TODO apps?

There are tens, if not hundreds of products to manage your todos, ranging from mobile applications to systematic ways to keep and organize a journal. At the core, they all do one thing: help you organize a list of things you “need” to get done. Some offer better interfaces, while others have a way to configure better reminders. All of these products compete on a functional level. They try to understand and improve the workflow you use to organize your todo items. At the functional level, the next company would improve that workflow. They would perform user and competitive research, understand the functional struggles, and build a better hierarchical drag-and-drop interface to organize your lists of todos.

But what if you take a step back? What if you try to understand why someone is trying to organize todos in the first place? Why have todos at all? Why do you have to prioritize and organize them? How many do you “have” to complete a day, and why? What happens if you don’t complete them?

The JTBD interview helps to uncover the emotional and social aspects of the job — like the feeling of running around with your hair on fire, the dooming sense of the list only getting longer, and going home feeling overwhelmed. Understanding these details behind these struggles would help us identify more innovative solutions. It would expand the solution space outside of just the functional nature of incessantly organizing and tracking a todo list.

If you think of a product as a function, tests for fitness should first and foremost measure your progress towards solving the emotional struggles.

It’s easy to relate to an emotional struggle as a consumer. We can all think of an emotional purchase we’ve made recently. But when we think about B2B products, it’s hard to make the same connection. B2B transactions are supposed to be objective and devoid of emotion. But this is no more true than the last-century economic theories based on the assumption that people behave rationally. B2B purchase decisions are made by people. Humans are emotional.

Emotional forces are as prevalent in B2B as they are in consumer purchases. As Gerald Zaltman’s research shows, consumers, whether in a B2C or B2B environment, make most of their decisions subconsciously, using their emotions. Focusing on only the functional elements limits your understanding of the real problem and prematurely constrains your solution space.

A couple of years ago, we were designing a diagnostics product for the automotive manufacturing industry. Our potential customers were large corporate organizations. In most B2B sales, there are numerous customers, ranging from the end-user to the buyer, and other roles up and across the organization. We were trying to settle on a reporting solution for our product. While interviewing a couple of end-users, we zoomed in on what reporting meant to them. Once we covered all the functional aspects of what their current system looks like and what data they wanted to see, we started to dig into the many layers of whys. This is where the emotional and social struggles begin to show. Those struggles included scrambling multiple times a day to consolidate data for their boss’ meeting, polishing the visualizations to look presentable to the executive committee, staying at work late into the night poring over disjoined quality data, etc. We weren’t just building a report to allow them to drill into the data; we were building a tool which helped them impress their boss, allowed them to go home in time for dinner with their family, and made them seem “on top of things” to their colleagues.

As another example, at my previous company, I interviewed a business owner who hired and then fired our product multiple times. The cycle went on for a while. When we finally dug in, it became apparent that a feature of our product, which we took a lot of time to refine and make easy to use, was causing her anxiety. She was afraid that if her clients looked over her shoulder, they’d think her job was easy and undermine her expertise. She wanted to prove to her clients that she had deep knowledge and expertise, but our design did the exact opposite. There were two competing jobs: emotional and functional. We built our software with an understanding of the functional struggles, but we weren’t able to convert the customer until we understood the emotions, which in turn allowed us to make different design tradeoffs.

As product developers, we’re used to uncovering the functional jobs. But the key to disruptive innovation lies in understanding emotion. In his article, Alan Klement makes a similar distinction between Be Goals (emotional) and Do Goals (functional). Be Goals, what you aspire to be/feel are at the heart of Jobs To Be Done. Be Goals are more stable in time and allow you to create more innovative solutions.

For as long as I’ve been working on software products, the process below or some variation of it has been the status quo.

1. You decide on a feature you want to build

2. You scope the work and break it into tasks

3. Developers estimate the tasks (either using time or some relative complexity measure) and the team starts the work

4. During the work, the team discovers things they didn’t previously know, which typically throws off the estimates

5. This results in scope creep and late deliveries

Some teams are better than others at estimating. Sometimes those teams are more experienced. Sometimes teams regularly estimate work that is similar to work they’ve done before. Or, they grossly overestimate all work on purpose.

In order to estimate better, you must remove any unknowns. But that’s impossible. Unless you’re doing the same work twice, it’s impossible to know all the obstacles that you’ll encounter. The only way to truly know how long something will take is to do it.

What if there was another way to think about scope? What if there was a more sane way to get what you want without ending up spending more time than it’s worth?

Appetite

Weekend is the time I prefer to spend with family, reflecting, thinking, and reading. Unfortunately, my life isn’t devoid of chores. For the last few weeks, I’ve been delaying cleaning our back yard. The procrastination is a natural response to my previous experiences. I typically plan on starting the chore early, hoping to finish by lunch time, and then envision myself enjoying the rest of the weekend. What usually happens, though, is quite different. I end up spending the majority of Saturday and part of Sunday doing the chore.

I love a clean back yard, but the tradeoff of wasting my weekend cleaning it is too much to bear.

What if I invert the process? Instead of first planning the yard work, I would ask myself, “How many hours am I willing to invest in having a clean yard?”

Surely, having a clean yard is a joy, but it’s relative to other things that are delightful as well.

This is what Ryan Singer labels as appetite in his new book Shape Up: “What is my appetite for a clean patio? How much time am I willing to invest?”

For me, it’s about 2–3 hours. With that appetite in hand, I’m able to make tradeoffs before I get started and during the cleaning. Surely I can’t do a meticulous job given that timeframe, but what can I do to still feel like I achieved a satisfactory outcome?

Now imagine this concept applied to product development. Instead of starting with scoping the work, you first ask, “What is my time appetite for solving this problem?” With that time constraint in hand, you have to get creative in designing the solution. These constraints also help you make tradeoffs during the implementation.

The notion of starting with appetite is ingenious. It inverses the scope estimate function and creates time constraints.

Constraints drive creativity and tradeoffs. Without them, there is rarely an end in sight.

This concept is discussed in depth in Ryan’s new book, Shape Up, where he describes in detail how Basecamp develops products.

Ryan is also doing a 2 day intense workshop with Bob Moesta in Detroit on Aug 28th and 29th. Day 1 you’ll learn the Job-to-be-done theory (what to build) and Day 2 you’ll learn the Shape Up method (how to build it).

For most successful companies or products you hear about these days, you hear stories about similar ideas that failed.

My idea was way ahead of its time. If I only waited a few (months, years, decades…).

The “bad timing” justification is given by pundits with little skin in the game or by the folks whose idea failed. Timing has become a trite excuse and, at the same time, a pompous puffery to support self-serving bias.

Short of ideas that depend on technology that is yet to be invented (e.g. building a car before the combustion engine is developed), timing is rarely the culprit.

Rather than timing, you can usually attribute the failure to one of these: failure to understand the consumer struggle and design a proper solution, failure to execute, or failure to acquire the necessary growth capital.

Failure to understand the consumer struggle and properly solve it

Products and companies exist to solve problems. They compete on different ways of doing it. But before you set out to solve a problem, you have to deeply understand it. Instead, many start with a shallow understanding, or worse, they start with a solution and then contrive the problem in support of their illusion.

This is what Steve Jobs meant when he said, “You have to start with the customer experience and work backwards to the technology.”

Failure to put the customer and their struggle at the center of the product is one of the main reasons companies and products fail.

One example from the Lean Startup book is a meal planning company called Food On The Table. They knew that their initial assumptions were most likely wrong. So, before they invested a single penny toward building a solution, they spent time at the grocery store talking to shoppers about their meal planning problems. They nailed the problem and the user experience first, and only then worked backwards to building a product.

No amount of meetings, white boarding, or coffee shop conversations will ever replace the deep understanding and empathy you get from talking to and observing actual customers (or struggling with the problem yourself).

Failure to execute

Even after you’ve done the hard part of refining your understanding of the problem and designing a good solution, you still have to execute. This is the differentiator between a great idea and a successful company.

Take Uber as an example of a ride hailing service. Many companies had similar ideas and built a product around it. Why did Uber prevail?

Besides building the necessary technology, they employed an army of field sales folks to sign up and onboard a critical mass of drivers. They also invested in lobbyists to influence municipal transportation laws in their favor.

Execution is not just a technological solution to the problem. It’s the hard work required to bring all the pieces together. It requires patience and perseverance. This is where most juicy problems with great ideas come to die.

Failure to acquire capital

In today’s world, technology allows many businesses to grow organically and require much less capital. However, some businesses require rapid scale to grow or need to acquire expensive capital assets. Inability to do this when needed is a common cause of business failure.

For example, if you’re a hardware company that makes wearables, you have to design and manufacture the board and the accompanying device. You then have to produce enough to ship. This requires much more capital than a purely software business. In most cases, you’ll have to raise or borrow money before you realize revenues.

Timing is a red herring

Timing is almost never the real reason a company fails. You’ll be much better analyzing the failure using the three culprits described in this post: failure to understand the consumer struggle and design a proper solution, failure to execute, or failure to acquire the necessary growth capital. Being aware of the true mechanisms for failure can help you avoid them.

I often hear of a company’s innovation roadmap. I’m always perplexed: How can something that is by nature amorphous have a blueprint? Vagueness is associated with risk, but I’ll argue that done right, the process of innovation actually reduces the risk and increases the robustness of the final product.

The flaw of the innovation roadmap

A roadmap is a rigid plan. It’s a recipe, a contract.

That last word, “contract,” is what makes the roadmap so ill-suited for innovation. A contract is a socially, financially, sometimes legally binding agreement. It forces you into a rigid execution plan, exactly the opposite of what’s needed during the process of discovery.

To innovate is to discover. You first uncover the struggles and then iterate to an optimum solution space. Discovery requires open-mindedness, flexibility, and the readiness to change paths.

With a contract in place, you’re less likely to breach it. Psychological biases will go in overdrive to keep the commitment. You’re less likely to make a change, just when you need it most.

Embracing the uncertain road ahead

In 1962, on a soul-searching trip around the world, Phil Knight stopped by Japan to visit a shoe manufacturer. He had only one goal: Convince the manufacturer to let him resell their shoes in the US. Almost 50 years later, Nike is the largest athletic shoe and apparel company in the world.

Through their journey, Nike revolutionized the world of sports shoe and apparel science, distribution, manufacturing, and athletic sponsorships. It was a destination reached by navigating treacherous terrains, missed turns, lucky breaks, and most of all, relentless grit. There were no long term plans or spurious revenue projections, but rather continuous and relentless adaptation and pursuit of progress. It was only later, once things stabilized, that they were able to articulate what they’ve become.

Adaptation is why they succeeded. At the end, these weren’t risks so much as they were systematic ways of building robustness while reducing the space of unknowns. The fabric needed to innovate.

Adaptation is more than just improvisation. It’s a systematic way of learning and thriving from failure.

Build antifragility into your DNA

When things don’t go as planned, and they will, how will you respond?

When you’re in the early stages of building something new, unknowns and failures need to be embraced. But embracing them is not enough. Your system must turn failures into gains. This type of system is called antifragile, as described by Nassim Taleb in his works. Antifragile systems not only reduce the risks of failure, but are able to thrive on them. Each failure leads to more robustness while decreasing the long-term risk.

This is because the process of innovation, in most domains, has a natural asymmetry between the gains and losses. Failures are mostly harmless and frequently beneficial, as they help reduce the space of unknowns. These benefits build upon each other exponentially. The way to reduce the risk of innovation is to build asymmetry into your process.

I once heard Jason Fried say: “Only the market tells the truth.” This is a great quote to keep in mind while trying to innovate. You must optimize for the market feedback loop. The better and faster it is, the faster you’ll iterate to a solution that fits.

Further reading

• Nassim Taleb. Start with Antifragile and then if you have time and interest, read the incerto.

• Running Lean by Ash Maurya

• The Four Steps to the Epiphany by Steve Blank

• Getting Real and Rework by Jason Fried and DHH

• Shoe Dog: A Memoir by the Creator of Nike