Thoughts on: Operations based solutions vs software based solutions
Software is cool, but duct tape is cheaper.
There is a natural tendency to overestimate software-driven solutions and underestimate operations-driven solutions. This bias leads to an over-investment in software and an under-investment in communication, process, experimentation, and deal-making.
Operations-based solutions tend to maximize outcomes within the constraints of today. A few examples:
The fastest way to improved internal efficiency is not to build a new internal tool but instead to cut scope and do less.
The fastest way to higher adoption is not to build a new onboarding feature but to individually connect with customers, understand their pain points, and onboard them.
The fastest way to drive more conversions is not to build an extra paid feature but to nail down communications, sales processes, pricing, or even run promotions.
Software, on the other hand, tends to break current constraints and expands the business’ problem-solving range and depth:
In the former scenario, a new internal efficiency tool could wipe an efficiency problem away completely by automating that workflow.
A new onboarding feature could establish a new floor for adoption.
A new paid feature could raise the conversion rates across the user base.
When businesses put all their eggs in the software basket they inevitably leave a lot of value on the table because every problem is weeks or months away from being solved and you can only really solve a few problems at a time. When businesses put all their eggs in the ops basket they can easily develop a short-sighted mindset present and create debt that’ll be hard to shake in the future.
It is true that operations solutions can break constraints and software solutions can optimize within constraints, signing a massive partnership, for example, is a transformative, ceiling-raising operations solution. However, this general mental model can help evaluate the right short-term and long-term approach to a problem.
Properties of each solution type:
Software-based solutions
Require a high degree of investment in terms of development but also in terms of integrating the new feature successfully into the business (building workflows, communication, support, sales, etc).
Carry long-term maintenance/support/optimization costs that are often overlooked.
Because of this overall cost, they have to deliver substantial amounts of value to achieve positive ROI. The investment cost is also almost always paid upfront.
Given the investment scope, businesses can also only afford to pursue a few solutions like this at a time.
Iteration cycles are slower as each cycle requires additional development which makes it harder to obtain results and validate the solution.
The total possible value for a solution of this kind is often very high since software can make almost anything possible.
Operations-based solutions
Generally have much lower upfront costs.
Are easier to manage, support, and discontinue long-term. Businesses can quickly abandon ops processes if these aren’t working.
This low-cost, low-commitment nature makes them easier to sign off on and leverage to extract value quickly.
Businesses can generally pursue a great number of ops solutions at any given time (although this capability creates coordination and cohesion challenges).
Iteration cycles are faster since each cycle has a low investment cost which makes it easier to obtain results and validate the solution.
The total possible value for a solution of this kind is limited by the constraints of the people, time, capabilities, and capital available to the business.
Given the difference in mechanics, each solution type is well-suited for certain problems but ill-suited for others. A few questions can be helpful to determine if ops or software is the right path for a problem:
Could we reasonably solve this without software? Would that solution be faster? Could we unlock 60-80% of the value with that approach? Is this something that we’re comfortable not building into the product?
If all are yes then an ops solution could reasonably solve the problem in a comparable way to software making it a good option.
If only some are yes then ops might still be well suited but ops is likely an intermediary solution or a precursor to a long-term software solution.
If all are no then this is very likely a software-shaped problem needing a software-based solution.
Software-based ops (hybrid model)
A new hybrid approach has become more prevalent with the rise of low-code platforms and LLMs. In many cases, hybrid solutions are fundamentally shaped like ops solutions in terms of cost and cycle speed but have payoffs that are more software-shaped. This makes them very well suited for a great deal of problems.
In particular, I’ve found these to be well-shaped for areas such as:
Internal efficiency (replacing pure software internal tooling)
Experimentation (expanding the possible experiments you can run),
Replacing high manual labor-based features (replacing things like customizable reports and assets, personalized email campaigns, and marketing page enablement).
How this concept affects PMs:
In many orgs, teams will become software-centric or ops-centric. I’ve found that it can often be the PM’s job to help teams delineate when one or the other is best suited. In creating this open-mindedness PMs and teams can become more effective and nimble in their problem-solving and collaboration.
Effective product management at a small company is often about maximizing the volume and quality of ops bets and software bets the business is making. Indexing too much on one or the other will often lead to disappointment. Software bets take too long to pay out and operations solutions can’t deliver the long-term upside the business needs to continue growing. By effectively leveraging both approaches businesses can effectively maximize opportunities short term while setting themselves up for high upside opportunities long term.