As someone who has spent over a decade in the tech industry building SaaS applications, I've learned that incorporating "teams" or multi-tenant functionality from the very beginning is crucial. It's a lesson many developers overlook, leading to significant challenges and user frustration down the line.

You might think, "My app is simple and designed for individual users. Do I really need to consider teams right now?" The answer is a resounding yes. Even seemingly straightforward applications, like a bookmark manager, eventually encounter users who want to share access—be it with family members, colleagues, or assistants. Humans are inherently social creatures, and our software needs to reflect that reality.

The Importance of Modeling Human Relationships

When we create software, we're essentially modeling aspects of the real world. If we neglect the concept of human relationships, we introduce a disconnect between how people naturally interact and how they use our applications. This mismatch can lead to user frustration and limit the potential growth of your product.

By incorporating teams functionality from the outset, you align your application with users' expectations and needs. It also saves you from the complex and often painful process of retrofitting this capability later on—a task that can consume significant time and resources.

Choosing the Right Foundation: "Organization" as Your Top-Level Entity

A critical step in building multi-tenant functionality is deciding what to call your top-level entity—the container that represents a group of users and their shared resources. Common terms include "Account," "Team," "Company," "Tenant," and "Workspace." Each has its drawbacks. For example:

Account can be confusing, as users might associate it with their personal login credentials.

Team might not be ideal if you plan to support multiple teams within a larger entity.

Company is too narrow if your users aren't all businesses.

Tenant isn't user-friendly or commonly understood outside technical circles.

Workspace is flexible but might be better suited as a sub-division within a larger group.

I recommend using "Organization" as your top-level entity. It's a versatile term that encompasses various types of groups, whether they're businesses, non-profits, or informal collectives. This choice sets a solid foundation for your application's data model and helps avoid confusion as your product evolves.

Different applications handle user access in various ways. Some allow a single user account to access multiple organizations (like GitHub), while others require separate accounts for each organization (similar to some Google services). There's also the approach used by the Linear app, which combines elements of both models. It allows users to access multiple organizations from a single account while also supporting separate accounts when necessary.

For most SaaS startups, a flexible model similar to the one used by the Linear app is ideal. It provides the best of both worlds, accommodating both individual and organizational use cases without imposing unnecessary constraints on the user.

In a multi-tenant system, it's essential to ensure that each organization's data is securely isolated from others. Think of it like an apartment building: residents share common spaces but have private living areas with controlled access. Your application should allow for similar isolation and shared access, supporting both individual use and collaboration within and across organizations.

Most resources in your application should belong to an organization rather than to individual users. This structure simplifies data management and enhances security. It also makes it easier to implement features like assigning tasks or projects to specific team members within an organization.

A critical aspect of multi-tenant functionality is the user experience around switching between organizations. Users should be able to move from one organization to another without having to log out and log back in. This seamless transition enhances usability, especially for consultants, freelancers, or anyone who collaborates with multiple organizations.

Implementing this requires thoughtful session management and authentication design. By allowing concurrent user sessions across multiple organizations, you provide a smoother and more intuitive experience that can set your product apart from competitors.

When it comes to billing, tie your subscriptions and payments to the organization rather than individual users. This approach aligns with how businesses manage expenses and simplifies account management for your customers.

Similarly, distinguish between global user settings and organization-specific settings. Global settings might include personal preferences like display themes, while organization-specific settings could cover notification preferences or role-based permissions. This separation ensures that users have a consistent experience across different organizations while still accommodating the unique needs of each group.

Implementing organization-level analytics from the start is vital. It not only helps you understand how your product is used but also provides valuable insights to your customers. By tracking usage patterns, you can make data-driven decisions to enhance your application and demonstrate value to your clients.

Designing your system with scalability in mind will save you from costly refactoring efforts in the future. Consider supporting features like parent-child organization relationships or accommodating various organization types. This foresight positions your product to handle increased complexity as your user base grows.

Integrating "teams" functionality from day one isn't just a technical decision—it's a strategic move that positions your SaaS product for long-term success. It aligns your software with the collaborative nature of how people work today, enhances user satisfaction, and makes your product more adaptable to a variety of use cases.

By anticipating your users' needs and building a flexible, multi-tenant architecture from the outset, you'll save yourself significant headaches down the line. More importantly, you'll create a product that not only meets but exceeds user expectations, setting the stage for sustained growth and success in the competitive SaaS landscape.

Building Multi-Tenant SaaS: Why "Teams" Functionality Should Be Day One Priority

Well, we've already made it a third of the way through the year. I'm wrapping up my honeymoon as I type this, and taking a break from work has been a nice refresh. It allows me to catch up on books and articles I've saved for later, and take a step back for a bit to refresh my perspective.

Recently, my preferred platform for media consumption has become Substack. I've just been gobbling up some great content on there! It's inspired me to sit back down at the old virtual writing desk, and take a stab at sharing some of what I've learned and found interesting recently with others who may fall in my digital bubble. In this post, I feel like writing about games, artificial intelligence, and compliments.

Here is a set of learning resources that I've put together on artificial intelligence, that should be fairly easy to digest, even if you aren't super technical:

One Useful Thing - Ethan Mollick's Blog on Practical Applications of AI in Learning and Business

Schillace Laws - A set of rules for how to best work with large language models as a software developer, written by Sam Schillace, deputy CTO at Microsoft and creator of Google Docs.

Prompt Engineering Guide - A lovely little site that goes in depth on different prompt engineering techniques with helpful examples.

A16Z - Andreesen Horowitz is one of my favorite VC firms to follow. They have a lovely collection of thought leadership on AI.

GitHub's Blog - I have long been a fan of GitHub's blog and R&D arm, GitHub Next. They have some fantastic material.

AI Pollution and the Tragedy of the Commons

If you haven't noticed the endless barrage of AI-generated images and "thought leadership" content on LinkedIn by now, you are either 1) not in the tech industry or tangential to it or 2) have been living under a rock. One of the more cringe-inducing features on LinkedIn that has recently fallen victim to this is the short-form "Answer a question" feature (you can do better LinkedIn).

Now, it's impossible (although some say the inclusion of the word "delve," or the wrapping up of a blog post with "In conclusion," are telltale signs of using Chat-GPT) to know for sure if these responses are AI-generated or assisted. Either way, there's a lot more content like this floating around nowadays, because it's just so easy to create now with LLMs. What are getting ourselves into? Maybe we need to revisit introducing more "Dislike" actions, like Facebook considered almost a decade ago.

A lot of people think the rapid uptick in low-quality content generation enabled by generative AI will “kill” the internet or drastically change it. It probably will. What will we see next though? Humans are resilient and innovative, so I’m looking forward to the next version of it. Are humans capable of designing a platform that prevents the tragedy of the commons, which doesn’t rely on an economy of eyeballs and clicks? In 2004, Aaron Swartz wrote a blog post about information freedom. Can information be regulated? Is there a technical solution to this, or do we rely on a collective swing of society to have a conscious positive impact?

In 2014, Warren Berger claimed in his book “A More Beautiful Question” that posits that questions are now more powerful than answers, because questions lead to innovation, and information is now freely and widely accessible. His rationale, is that it is inevitable that human information would become stored in a database that we could all access.

The sheer amount of information humans rely on to take action now is far too great for any brain to hold. So for the last two or three decades, we've been heading towards a world in which we gain the vast amount of our information from databases. And now, more recently, a computer (e.g., Chat-GPT) tells us the best information collected from the best resources. While this can sound daunting to some, there there is a tremendous upside to this - reduced decision fatigue.

I love Lazarus Lake’s approach to game design. He is something of a celebrity in the ultra-running community. He cropped up on my radar recently, after reading Frank Lantz's wonderfully eloquent piece on him. You should read it. Also, Lazarus Lake spoke on a podcast recently that is equally worth consuming. What I'm so enamored with is how he's bending seriousness, but not disregarding it. Lake's games remind me of Thorsten Brinkmann in some ways, blending ceremony with the peculiar. Lantz articulates it far better than I can, with the following quote:

"When they aren’t trying to manipulate you, most modern games are desperately trying to please you, carefully designed to capture and hold your attention, constantly trying to explain and justify themselves, and sweatily working to amuse and entertain you. When your game is a product every sharp edge is a flaw, a leak, an opportunity for the precious attention you are harvesting to escape back into the ether. Lake’s games are also carefully designed, they are full of closely-considered details that fit together to make a coherent whole, but the problem they are trying to solve is an entirely different one. They are not bowing and scraping to accommodate your needs while secretly plotting to hypnotize you into a state of passive thrall. Their parts fit together like the plants, rocks, and mud of a Tennessee mountain, and, like that mountain, they will happily, indifferently, shrug you off. And yet, somehow, the resulting experience expresses a deep level of respect and compassion." -Frank Lantz

Take some of these rules from Lazarus Lake's infamous Barkley Marathon that is organized each year and notoriously difficult to register for:

The start time occurs between midnight and noon. However, racers are never told when the race will officially start. The only indication they receive for the start time is by Cantrell blowing a conch shell, which could come in the middle of the night, to signify that the race will start exactly one hour from that time.

Once the hour is up, runners line up at the yellow gate at a campground within Frozen Head State Park. When Cantrell lights a cigarette, that starts the race along with the clock.

The bib is very important in this race. It does not track the runner or splits; rather, each loop requires runners to make it to various points in the park. At those checkpoints are books that Cantrell has placed there. Your bib number is the page number you need to rip out of that book. Typically, nine to 11 books are placed in the woods, and if you are missing a page then you didn’t officially complete the loop.

I hope some day to design a game. It's... somewhere... on my bucket list. Not sure when I will, but when I do, I plan on drawing inspiration from Lazarus Lake.

The other day I ran into a long-time friend of mine whom I rarely see (the older sister of one of my close high school friends). She shared with me that the mix CDs that I burnt for some of my friends, including her sister, made a lasting impression on her musical preferences, and she was thankful for that. It was very kind of her to share that with me, and it made my day. I sometimes forget how powerful and energizing a sincere compliment can be in the receiver's life. If you're reading this, thanks for that A.H.!

Here are some things I've found enjoyable recently:

Book: "Scaling People: Tactics for Management and Company Building" -Claire Hughes Johnson

Song: "Agape" -Nicholas Britell (fun fact, he wrote the theme for Succession)

TV: Succession (I've recently jumped into it, and am loving it! It's one of those series I knew would be good, but held off on watching for a while)

I've recently gone down quite a rabbit hole with Frank Lantz and intend to read "The Beauty of Games" in full here shortly. I also plan to read "Gravity's Rainbow," because I'm a bit obsessed with Thomas Pynchon's concept of temporal bandwidth.

Some of my favorite takeaways from day 1 at Figma's Config 2023 Conference, which was jam-packed with some quality presentations from heavy-hitters in the tech and design communities.

The first day of Figma Config 2023 was jam-packed with talks from some heavy hitters in the design and tech communities. This is a recap of some of my favorite sessions of the day, related to the creator community and the characteristics of delightful software.

Day 1 of Figma's hybrid virtual/in-person conference, Config 2023, was practically seamless from a technical standpoint. There have been some real shit-shows over the past couple of years when it comes to virtual event productions. I know it's not an easy undertaking, so kudos to all involved in this year's production. Two talks that stood out were by Andrew Schmidt on delightful design and Amiad Masad on enabling new creators of software.

Andrew Schmidt, gave a delightful talk (pun intended) on the characteristics that embody good software, and how they're pre-requisites for creators to consider before pulling out their bag of overused tricks for novel/kitschy "delight" (think confetti, silly micro-interactions, and overly conversational UX copy). He proposed that delightful software should be tactile, inspiring, considerate, comfy, and empowering. At the end of his talk, he reiterated that when your software does characterize these different qualities, the icing on the cake is letting humanity shine through in your design. Just be careful not to get too "cute" with your product before accounting for those fundamental qualities.

Schmidt was one of the best conference presenters I have listened to in quite some time. Even if you're not that interested in the content, I highly recommend watching the video (skip to the halfway point to get to Schmidt's portion of the talk). His storytelling ability and presentation are top-notch.

Should designers c̶o̶d̶e̶ create software?

In another session, Amjad Masad, CEO of Replit, presented a thought-provoking talk on the evolving role of designers in the software industry. He proposed a shift in the question from "Should designers code?" to "Should designers write software?" This shift in perspective is significant. It suggests that designers should not merely be involved in the aesthetic and usability aspects of software but should also contribute to its creation and development. With the advent of AI-enabled platforms and tools, as well as a whole slew of low-code/no-code solutions available to consumers, I imagine the role of developers in the overall product development lifecycle will continue to diminish. The developer role will never go away entirely, but we will definitely see a stronger shift towards DesignOps over the next couple of years, with more focus on high fidelity prototypes and shorter development cycles.

Looking forward to tuning in for tomorrow's sessions. If you're interested in checking out the schedule, you can find everything on Figma's event page.

Figma Config 2023 Day 1 Recap: Delightful Design and Empowering New Creators

When organizations hire consultants, they often expect them to deliver specific outcomes. One lesser mentioned value-add from hiring consultants lies in their ability to see beyond their defined roles and notice high-value opportunities.

Friends and family often have a hard time understanding exactly what I do. Unlike other professions, consulting offers no shortage of unique challenges, tasks, and responsibilities. In my division of consulting (tech), consultants are typically hired by companies to provide unbiased perspectives or advice, to help establish architectures (product, technical, enterprise, data), or to build systems (products, integrations, automations, etc.) in order to help businesses thrive. We're expected to quickly navigate the intricacies of the digital landscape at a client and ramp up quickly on their specific tools, processes, org structure, and business domain.

During one of my team's projects, we stumbled upon a quick win that proved surprisingly valuable for our client. Our focus at the client was product development - we were simultaneously helping them modernize legacy apps and refactor their product architecture to support a "product through composition" model. When we started the initial design process to migrate Single-Sign-On (SSO) over from a systems standpoint, the client provided helpful context about their existing identity provider - including how much they were paying for it. While their existing identity platform was well-known in the industry, we wouldn't consider it one of our first picks if architecting from the ground up. Knowing this, combined with our newly learned cost considerations, we quickly provided a recommended alternative. Since we've implemented auth and identity solutions across dozens of clients, it was easy for us to identify an opportunity for improvement.

The client was open to exploring an alternative tool/platform, and approved a quick proof-of-concept that allowed us to validate that it would check all of the boxes. Once we validated it, it took less than one sprint (two weeks) to incorporate into the product. With the help of feature flags, we were able to deliberately roll it out to specific customers as we worked with their IT teams to coordinate the change.

This tooling overhaul had a couple of significant benefits:

From a cost standpoint, our client was able to realize cost savings of over $100,000 annually

From a product standpoint, the new platform had vastly superior documentation and integration/setup tooling. We were able to eliminate the need for our clients Solution Engineers to assist their customers with SSO setup, and move it to a 100% self-service model. Setup time shifted from days to minutes, and freed up valuable time for our client's engineers. 

Consultants bring a fresh set of eyes and an outside perspective to the table. We aren't tied down by internal biases or preconceived notions, allowing us to objectively evaluate systems and processes. In this particular case, our ability to question the status quo and identify potential areas for improvement set the stage for significant cost optimization and improved customer experience.

Regardless of your industry, or position at your company, you can have a positive impact on driving business value at your organization by considering the following practices.

Companies both large and small can benefit from establishing relationships with consultants. They can be extremely valuable contacts to have in your Rolodex. If you've never used a consultant before, feel free to reach out to me! I'd be happy to direct you to some of the people in my network that may be well-suited to help you. It's very much a relationship-based industry, so it can be difficult to find a place to start sometimes. Also, most consulting firms are generally happy to provide you some thought leadership and a project proposal at no cost. These can be helpful insights to help you decide who to go with from a partner standpoint. One other thing to note is that depending on the size of your firm, it can be helpful to diversify your partnerships with at least two - this will help ensure competitive pricing. Just be sure to foster a spirit of collaboration, not competition, which can easily kill the success of your most valuable initiatives.

Be open and transparent internally - both with your people and with external partners. Your best interests are generally in the best interest of your partners and your people. Air on the side of sharing information vs. gatekeeping it. Sometimes, even utilizing the appropriate workspace management platform can be a great first step in creating a community of collaboration.

Different industries have different appetites for failure. Define what failure and experimentation mean for your organization, and how you can leverage them to build value. Failing is good. It means you are experimenting. Spend some time with your team to see how you can intentionally create space for experimentation in your day-to-day. They can be the most valuable mechanisms for validating value. One way you can easily do this, is by allocating a percentage of your roadmap to exploration and experimentation.

Hopefully this short case study illustrates the potential value that consultants can bring beyond their defined roles and how, with or without consultants, you can create space within your organization to discover those hidden gems yourself. Thanks for reading!

As web development has evolved, modern design tools/systems like Material Design and Tailwind have undeniably facilitated acceleration and scale, leading to impressive advancements in the digital landscape. However, this progress has come at a cost—the charming, eclectic nature of the web's earlier days has been largely replaced by streamlined, uniform designs. In this article, we will reminisce about the "messier" web of the past and explore how modern design tools have contributed to a more polished yet less endearing digital world.

One of my all-time favorite sites is sreweb.com. I happened across it when seeing the URL called out in large block-letter signage of mismatched sizes and fonts on the side of a building from the highway. When I visited it, I was absolutely delighted - it was an absolute blast to the past, bringing back to the Geocities days. There was a time when the web was a wild, uncharted territory, with websites embracing a wide variety of designs, animations, and artistic expressions. Some aspects that made the web of the past so charming include:

Unique and Personalized Design: Websites were often handcrafted by individual developers or small teams, resulting in unique designs that reflected the creators' personalities and artistic visions.

Creative Freedom: The lack of established design patterns and best practices allowed for greater creative freedom, leading to a vast array of experimental layouts and visual styles.

A Sense of Exploration: The unpredictable nature of the early web fostered a sense of exploration and discovery, as users stumbled upon new and unexpected websites during their digital journeys.

The rise of modern UI frameworks, such as MUI, Ant Design, and Chakra (among many), has undeniably revolutionized web development, bringing significant benefits like improved performance, scalability, and maintainability. However, these frameworks have also contributed to the disappearance of the web's more charming aspects.

The widespread adoption of design systems has led to a more standardized design aesthetic, reducing the diversity and individuality of websites. As best practices and design patterns have become more established, developers are often encouraged to conform to these guidelines, potentially stifling creativity and experimentation.

While it's unrealistic to abandon modern tools and return to the web's earlier days, there are ways to create space for some of the charm and personality that once defined the digital landscape:

Encourage Creativity: Give developers and designers the freedom to think outside the box and explore innovative design solutions, even if they challenge established patterns and practices.

Embrace Uniqueness: Strive to create websites that reflect the unique identity and values of a brand, rather than simply adhering to the latest design trends.

Prioritize Storytelling: Focus on crafting engaging and delightful user experiences that prioritize aesthetics and storytelling, alongside performance and functionality.

Some products, like mmm.page, are embracing the sticker-like aesthetics of mid-90s web. They're intentionally leaning into a "slap it together" mentality when it comes to their page builder platform.

mmm.page, a fun spin on modern site building

I'm hopeful and optimistic that as today's designers and technologists continue to push the boundaries of what's possible on the web, we'll continue to carve out some space for the crunchy, the noisy, the ugly, and the unexplainable. After all, that's what makes the web so wonderful.

Nostalgia for a Messier Web: The Charm of the Past and the Impact of Modern UI Frameworks

The landscape of digital product management is rapidly evolving, with the growing adoption of component-based architectures and modern front-end frameworks. In order to keep up with the pace of change, digital product managers need to adapt their approach to product requirements by focusing on components rather than relying solely on traditional user stories.

The Shift Towards Component-Centric Development

Component-based development has become increasingly popular due to its ability to promote code reuse, modularity, and maintainability. With the rise of front-end frameworks like React, Angular, and Vue.js, the concept of components has become an integral part of modern web application development. This shift towards component-centric development calls for a new approach to product requirements that aligns with this modular mindset.

Why Digital Product Managers Need to Understand Components

Understanding components is essential for digital product managers because it allows them to:

Improve Collaboration: A strong grasp of components helps product managers collaborate more effectively with developers, facilitating better communication and shared understanding of the product's structure and requirements.

Foster Reusability: By understanding components, product managers can identify opportunities for code reuse, leading to more efficient development and a consistent user experience across the product.

Streamline the Development Process: Component-centric requirements make it easier for developers to estimate, prioritize, and implement features, resulting in a more efficient development process.

Enhance Product Scalability and Maintainability: Components promote modularity and maintainability, which are crucial for building scalable and easily maintainable digital products.

Framing Product Requirements in the Context of Components

To better frame product requirements in the context of components, digital product managers should consider the following steps:

Identify and Define Components: Begin by identifying the key components that make up the product's user interface and functionality. Clearly define the purpose and responsibilities of each component to provide a solid foundation for the development team.

Create Component-Based User Stories: Instead of writing traditional user stories, focus on creating component-based user stories that describe the desired functionality, interactions, and states of each component. This approach enables developers to better understand the intended behavior of each component within the larger product context.

Establish a Component Library: Work closely with developers to create a shared component library that documents the available components, their props, and their usage. This library serves as a single source of truth for the entire team, making it easier to understand, reuse, and maintain components across the product.

Collaborate with Designers and Developers: Engage in ongoing collaboration with designers and developers to ensure that the components align with the product's overall design and functionality. This collaboration will help create a cohesive user experience and streamline the development process.

As the digital product landscape evolves towards component-centric development, it's crucial for product managers to adapt their approach to product requirements. By understanding components and focusing on component-based user stories, product managers can enhance collaboration with developers, foster reusability, and streamline the development process. Embracing this component-centric mindset will not only improve the efficiency and effectiveness of product management but also contribute to the successful delivery of high-quality digital products that meet user needs and expectations.

Moving Beyond Traditional User Stories to Component-Centric Requirements

The landscape of enterprise software development is experiencing a significant shift, with the emergence of composable architectures and low-code/no-code solutions. These innovations are challenging the traditional approach to custom application development, offering a more flexible, efficient, and cost-effective alternative. In this article, we'll explore how these technologies are transforming the way enterprises create software, potentially eliminating the need for traditional custom application development.

Composable Architectures: Modular and Flexible Solutions

Composable architectures allow businesses to build software solutions by combining modular, pre-built components. This approach enables organizations to create applications quickly and with minimal coding, as they can assemble the required components to meet their specific needs. The benefits of composable architectures include:

Flexibility and Adaptability: Composable architectures allow businesses to easily adapt their applications to changing requirements, as they can add, remove, or modify components without affecting the entire system.

Speed and Efficiency: By using pre-built components, businesses can significantly reduce development time, enabling them to bring new solutions to market more quickly.

Reduced Costs: Composable architectures can help organizations save on development costs, as they can leverage existing components rather than building everything from scratch.

Low-Code/No-Code Solutions: Democratizing Application Development

Low-code and no-code platforms are designed to empower non-developers to create software solutions with minimal coding expertise. These platforms provide visual development environments, drag-and-drop components, and pre-built templates, allowing users to build applications quickly and easily. The advantages of low-code/no-code solutions include:

Broader Access to Software Development: Low-code/no-code platforms democratize the application development process, allowing employees from various departments to contribute to the creation of software solutions.

Accelerated Time-to-Market: By simplifying the development process, low-code/no-code platforms enable businesses to create and deploy applications faster, reducing time-to-market.

Cost Savings: Low-code/no-code solutions can help organizations save on development costs by minimizing the need for specialized developers and reducing the reliance on external vendors.

The Implications for Custom Application Development

As composable architectures and low-code/no-code solutions gain traction, the demand for traditional custom application development may diminish. These technologies offer several advantages over traditional development, including:

Reduced Complexity: Composable architectures and low-code/no-code platforms simplify the application development process, making it more accessible to a wider range of stakeholders within an organization.

Greater Agility: These solutions enable businesses to respond more quickly to changing requirements and market conditions, as they can easily modify their applications to adapt to new needs.

Cost Efficiency: By leveraging pre-built components and minimizing the need for specialized developers, businesses can significantly reduce the costs associated with custom application development.

Composable architectures and low-code/no-code solutions are redefining the enterprise software landscape, offering a more efficient, flexible, and cost-effective alternative to traditional custom application development. While there may always be a place for custom development in certain scenarios, the growing popularity of these innovative technologies suggests that the future of enterprise software may lie in modular, user-friendly solutions that empower businesses to create applications quickly and easily, without relying on specialized development expertise.

The Future of Enterprise Systems: Composable and Low/No-Code Solutions

Software development doesn't have to be fast. Often times, slowness is the right approach to delivering quality. The modern world has seen a shift towards agile development practices, with its emphasis on speed, constant iteration, and fast feedback loops. However, a continuous focus on rapid development can lead to burnout and overlook the importance of pausing to reflect and realign.

In the new post-COVID norm, with days running together with endless video calls, time, for many, began to lose meaning. For those of us working from home, our online hours provided structure to otherwise shapeless swaths of minutes and days. That is, until those hours online began to blend together too, and the days, weeks, and months fused into a single blur. 

It's happened to me, and I'm sure multiple teammates and colleagues of mine would agree as well. At work, daily stand-ups began to feel scripted, each sprint indistinguishable from the last. My team planned and shipped new features at a rapid clip, but the work began to feel never-ending. This constant, iterative development is a hallmark of the agile process, the standard for software development today—but if you’re anything like me, the past couple of years have left you wondering whether it’s actually useful. Maybe, in our emphasis on incremental development, we’ve overlooked an essential element: the space to slow down.

Agile development involves building software incrementally, allowing teams to react swiftly to user feedback and adjust products as needed. This iterative process generates momentum, with each sprint moving the software closer to its ideal state. However, continuously adding small features can become monotonous and lead to burnout, especially for mature, feature-complete projects.

The waterfall method, although less nimble than agile, incorporated milestones as a way to delineate project phases and allocate time for reflection. While agile development has retrospectives, these meetings are often seen as procedural and unproductive, diminishing their effectiveness.

Introducing milestones into the agile process can provide teams with dedicated time to pause, reflect, and plan for the next phase of development. By implementing milestones after several sprints or at regular intervals, teams can break from the sprint cycle and refocus on the bigger picture.

By integrating milestones into agile development, teams can create room for introspection and holistic consideration of products and processes. This blend of agile practices with elements of the waterfall method can establish a steady, sustainable rhythm, promoting better software development and a healthier work-life balance.

Product development often involves a multitude of ideas and potential projects, making prioritization a significant challenge. The RICE model provides a systematic approach to this issue, enabling product managers to evaluate and rank projects based on four key factors: Reach, Impact, Confidence, and Effort.

Here's a brief explanation of each factor:

Reach: This refers to the number of people a project will affect within a specific period. It's quantified in terms of people or events per time period, such as "customers per quarter" or "transactions per month".

Impact: This estimates the effect of a project on an individual. It's measured on a scale ranging from 0.25 for "minimal" impact to 3 for "massive" impact. In other words, a project with a "massive" impact is given a score three times higher than one with a "medium" impact.

Confidence: This is a percentage that reflects the degree of certainty in the estimates for Reach and Impact. It's a tool to control enthusiasm for exciting but ill-defined ideas. High confidence is marked at 100%, medium at 80%, and low at 50%.

Effort: This represents the total time a project will require from all team members. It's estimated in "person-months", the work that one team member can do in a month. The estimates are kept rough, using whole numbers and a minimum of half a month to avoid getting into the weeds of estimation.

The RICE score is calculated using the formula:

RICE Score = (Reach * Impact * Confidence) / Effort

This score measures the total impact per time worked, which is the ultimate goal of prioritization.

While the RICE model provides a structured approach to prioritization, it's not an absolute rule. There may be instances where projects with lower scores are prioritized due to dependencies or specific customer requirements. However, the RICE model ensures that such decisions are well-informed and justifiable.

RICE: A Simple Approach to Prioritizing Product Development

John Salvie

Nov 15, 2024

Building Multi-Tenant SaaS: Why "Teams" Functionality Should Be Day One Priority

Apr 29, 2024

Ramblings on AI and Lazarus Lake

Jun 23, 2023

Figma Config 2023 Day 1 Recap: Delightful Design and Empowering New Creators

Jun 20, 2023

Hidden Gems in Plain Sight

Apr 20, 2023

Nostalgia for a Messier Web: The Charm of the Past and the Impact of Modern UI Frameworks

Mar 8, 2023

Moving Beyond Traditional User Stories to Component-Centric Requirements

Feb 10, 2023

The Future of Enterprise Systems: Composable and Low/No-Code Solutions

Jun 27, 2022

Embracing Slowness

Jan 18, 2021

RICE: A Simple Approach to Prioritizing Product Development