Despite all startups being resource-poor relative to what they are trying to achieve, many founders invest in solutions (e.g., specific product features, technology improvements, and internal systems/processes) that require effort beyond what is desirable from an ROI perspective. This happens for many reasons: founders might be taking advice or inspiration from larger companies who need more than they do, they may fail to focus on desired outcomes, or they could underestimate how much work is required for the solutions they're championing. Most scale-ups and larger companies also suffer from bloated solutions. My advice for getting things done with minimal waste is to focus on outcomes and problems without getting too attached to the obvious solutions, try to home in onto a minimum effective dose solution, integrate processes into ongoing operational rituals, and to frequently reflect on how these things are performing to ensure continuous improvement.

Jumping to solutions is the first mistake people tend to make when solving problems. Solutions often arise first, with the problems they solve being implicit and undefined. By committing to an approach before exploring the problem, you are at a high risk of implementing one that requires more effort than is necessary to solve the problem — it might not even solve the implicit problem you're attempting to address. Defining the problem and finding consensus from stakeholders is the oft-skipped initial step toward overcoming any challenge. Whether your goal is to address a challenge faced by your customers (most likely to require some new product functionality) or an internal issue/inefficiency (most likely to require a new process), by outlining the problem in a way that does not mention any specific solutions, you give yourself a way to later determine what proposed solutions will best resolve the outlined challenge.

For example, most companies eventually need a process for onboarding new staff. There is rarely a defined process for onboarding the first few employees at an early-stage company, leading to pain as the team grows. Solutions to this problem immediately come to mind for most people (e.g., "we need an induction program for new employees that involves some technical training, social introductions and shadowing"). These solutions seem so apparent that most teams will go ahead and invest in building this out without giving too much thought to the specific issues being solved. Teams that inspect the problem first may notice that new employees only struggle with particular elements of starting in their roles, and parts of the solution that seem obvious are unnecessary. For example, new starters might not have much trouble getting their heads around their roles' technical side; therefore, the onboarding training element can wait until later. Additionally, there could be challenges for new starters that are relatively unique to the company and have been missed from the obvious solution.

Notably, while there are many problems that most organisations face in common, the details vary significantly, and solutions should too. Teams that take the time to outline their challenges and desired outcomes before they get attached to specific solutions will find more targeted, less wasteful answers (i.e., don't include as much work that will prove unnecessary). The best solutions embrace the minimum effective dose principle: what is the slightest investment of effort we can make to solve this problem effectively? In product development, the minimum viable product framework is a well-established application of this principle, but it also applies to internal processes and tools. By focusing on outcomes and the problem to be solved, teams can reduce the scope of their solutions to a fraction of their initial idea, allowing them to depend less on risky assumptions and more quickly move on to the next problem. MVP-skeptics often criticise how the MVP approach can lead to a wide range of good enough solutions or features and nothing that goes deep enough to differentiate the product or business from the competition. This happens when teams do an excellent job of reducing scope but fail to iterate on what they have built.

Iterative improvement is key to starting small to move quickly and create something great. The best products, processes, and solutions are self-improving. For products, this means they have teams that own them long-term, without too much on their plate at once, that not only start small but consistently invest in delivering frequent iterative improvements. For processes and business operations, this means ensuring somebody is responsible and accountable for reflecting on how well they work and improving them over time. Ideally, the performance of operational tactics is measured. Business operations that are ownerless and unmeasured inevitably fall by the wayside. For example, someone (e.g., HR managers, team leaders, or recruiters) should own the aforementioned onboarding process and performance measures (e.g., employee NPS for new staff, time until effective) should be associated with them. Opportunities to improve any process should be identified and prioritised as a regular review of how that process is performing. If this feels too demanding, this could indicate that a process is not required to solve the problem (i.e., if the solution feels too big, the problem may be too small). Capturing feedback from stakeholders is another critical component of constant improvement. Consider this when building products (feedback gathering should be integrated into user interfaces) and business processes (impacted stakeholders should be surveyed on the effectiveness of the process), and try to incorporate feedback into reflection rituals like retrospectives and reviews.

Lastly, when building new features or implementing new processes, it is valuable to create internal documentation as you go. Internal documentation is an ideal location for capturing feedback and enabling others to contribute to the process. An open and collaborative business operations culture is the best way to encourage the evolution of processes over time.