Two belaboured topics in the product development community are the operationalisation of software costs (i.e., the SaaS-ification of everything) and the movement from project teams to product teams. I think what many product professionals miss is the deep connection between these two movements, and how this impacts the importance of the latter transformation for all SaaS companies.

Businesses have always required tools to get work done. Traditionally, these tools have been acquired up front, and used on an ongoing basis until the expiry of the tool (i.e., the tool breaks), after which an (often improved) replacement is procured. Farms buy ploughs, factories buy machinery, presses by a printing press. Since the early days of the software industry, many companies have bought software this same way. Businesses call this process of pre-purchasing equipment that will aid a project capital expenditure.

At first, it made sense for the software industry to mimic the existing business models employed by other tool manufacturers. But, today, this business model is increasingly rare for software businesses. This is because of the rise of Software as a Service, the model where software (and support services) is effectively rented on a monthly, quarterly, or annual basis. This is enabled by the low marginal costs that come with digital goods — because software developers do not need to pay anything upfront to "manufacture" their software for each new user, they do not need to charge their customers upfront. This dramatically lowers the barrier to entry for businesses that require software as they no longer need to invest a large chunk of capital upfront. Instead, they can license any required software, paying for what they use as they use it. This moves software licensing fees away from capital expenditure and towards operational expenditure (i.e., regular business-as-usual costs). In the industry, we've referred to this as the operationalisation of costs.

This is all very SaaS 101 and probably goes without saying for most people working within the software industry. What I find interesting, though, is that while most of the software industry has now adopted the SaaS model and operationalised their revenue (i.e., they receive regular, ongoing payments for their products, rather than one-off payments that require new products to be sold in order to get more revenue from existing customers), many have not operationalised their own costs in that they still allocate capital on a project-by-project basis.

Let's dig deeper into this idea. So, we've established that as a software vendor, our customers can invest in tools either through capital expenditure (upfront purchasing of tools with a limited lifetime) or operational expenditure (regular business-as-usual costs). The same model applies to you as a software vendor: do build your product through capital expenditure (i.e., we will invest $450,000 into this project) or operational expenditure (i.e., we invest in this product on an ongoing basis, this cost line never goes away).

In the traditional model, investment of R&D was typically aligned with the sales model. In the same way that software products were sold as one-off sales to the customer, these products were invested in as projects. ROI was simply calculated by looking at how much we spent on ACME Software App Version 2, and how many customers bought it. Many SaaS companies still use this outdated model when it comes to product development. They imagine new revenue lines (e.g., a new product or feature) as projects to be prioritised and completed, after which the team can move on to the next product on the list. This model is flawed because it misaligns the incentives of the software vendor away from the best interests of their customers.

Before SaaS, products were completed before they were sold (this sounds like pointing out the obvious, but it really is very different to how software works today). Just like any tool in the physical world, when you bought software, you bought it in its current state, and it generally stayed pretty much the same from then onwards. In the world of SaaS, customers are repurchasing your product every single pay cycle. The same low costs of adoption that made it easy for you to sell your product to your customer without upfront capital expenditure also make it very easy for your customer to adopt a competitive product if it becomes more suitable. Therefore, it is critical for SaaS products to improve throughout the lifecycle of a customer (though the bar for how much a product may need to improve over time varies based on the maturity of the product and the market niche being addressed). In SaaS, you are technically reselling your product to every customer every month, quarter, or year. While automated billing turns this resale into a passive process on behalf of the customer, you should still think about renewals this way: you need to remain the most suitable product for the customers in your market niche on an ongoing basis.

The best way to achieve this ongoing success is to operationalise your investment in product development, aligning your costs with your revenues. Products are re-purchased every month, so they need to improve at that same pace. Instead of budgeting on a project-by-project basis, allocate ongoing resources towards products in your portfolio.

Practically, this looks like:

• Align teams to products instead of projects. Product teams are long-lived teams that have ownership over a product, rather than teams that bounce between products and projects.
• Any product with customers also needs developers. If your product has a customer, it needs development resources there to maintain and improve it. If you can't justify this for a particular product, you should probably kill this product.
• Products are not projects. New products should not be built with a project mentality. They must be built with a product mentality. This means you need to spin up a new team, dedicated in the long-term to this new product. This may not be necessary for explorations and proof-of-concepts, but by the time you're ready to get some customers, you need a team.
• Measure the success of your products over projects. It's most valuable to establish long-term, product-wide success measures that all of your initiatives will work towards improving. Individual initiatives might have their own success or failure indicators, but these should be aligned to the success measures for your product. If these become difficult to align with your product, you may be working on the wrong things. Alternatively, you may be stumbling into a new product, for which you need a new team.

This transformation is much more difficult than the business model transition that most software companies have now completed. Operationalising software revenue has proven much easier than operationalising the investment of capital. But, for long-term success as a SaaS business, this needs to be done.

A common topic in product companies is the prioritisation of so-called customer-facing initiatives versus so-called technical initiatives (e.g., automated testing, reusable technical patterns, SDKs, automation, API-first services). The debate usually goes like this:

1. We should focus on delivering customer value over anything. With our limited resources, any investment in non-critical technical work will only delay the features customers need.
2. We need to invest in technical excellence now. If we don't, we'll have reliability issues and be inundated with technical debt.

The common-sense answer for all companies is to strike a balance between these two approaches. A company should not spend 100% of its resources on gold-plated technical foundations on which no customer value is ever built. At the same time, neglecting technical foundations self-destructive in the long term.

One way to look at this is by the stage of the company:

1. Early-stage product companies are operating in a context of low confidence in their solutions because they are still looking for product-market fit. They probably don't have a firm understanding of what they should build because they are still exploring what problems the market wants them to solve. In this context, it often makes sense to prioritise short-term product development velocity over long-term momentum because there is not yet any certainty on what features will end up useful or even whether the business will exist in the long term. Thus, a less technically excellent approach may make sense during this phase.
2. Companies that have found product-market fit, and therefore have a pretty strong thesis for how they will scale, should be focused on scalability and optimisation. Strong technical foundations are critical to scalability and should therefore be a major focus.

The transition between the two stages above can be very difficult for product companies. In some circumstances, companies will find product-market fit before a significant amount of technical debt has built up, so starting to focus on technical foundations feels like nothing but a significant slowing of product development velocity. In most circumstances, technical debt has likely become a problem by the time product-market fit has been achieved, and the transition is even more difficult because the prescribed solution to velocity that has been slowing down (due to mounting technical debt) is a further (temporary) slowdown to pay back this debt and lay better technical foundations. This dilemma traps many companies into a very unhealthy cycle, where the bar for technical debt to be addressed becomes very high (i.e., essentially just critical bugs and security issues), so technical work is a burden to begrudgingly be addressed, rather than a valuable investment in critical foundations. This approach gradually slows development momentum to a crawl which can kill product companies if the need to build quickly should ever arise (e.g., disruption from competitors).

Resistance to technical investment is understandable — the solution to delivery inertia caused by technical debt feels like a further reduction in speed of delivery because it is. The two major changes usually required are:

• A pause in feature development to focus on paying back debt and building better foundations for the future (e.g., writing tests for legacy code), thus delaying features on the roadmap for some time.
• The padding of future work with additional technical effort (e.g., writing tests), thus slowing down the delivery of features in comparison to what the business is accustomed to.

The value, though, is that eventually, this alleviates the already existing inertia that is compounded by a lack of investment in technical debt, with the net outcome being an increase in speed of delivery. This shouldn't just be thought of as debt, which implies that technical work is a burden to be begrudgingly addressed. Just as you can be disadvantaged by technical debt, you can also be advantaged by technical wealth. Put another way, by investing more in great technical foundations, you can see benefits beyond simply paying down debt to keep things moving at an acceptable pace (e.g., it is difficult to build in an API-first approach when you don't have good foundations and patterns for how new APIs should be built. Pausing now to build some great foundations for future API services might delay the delivery of your first API, but it will speed up the delivery of subsequent APIs and simplify maintenance in the long term).

In summary, product leaders should think more about the positive outcomes of technical investment, rather than simply view technical work as a burden to be addressed to avoid negative outcomes. Product strategists need to understand the value of this work and ensure it gets prioritised. Many technical leaders need a better appreciation for the value of sprinting towards product-market fit in the early days of the company, and businesses need to transition away from this approach before technical debt becomes insurmountable (with ample appreciation for how difficult this transition is).

Comparing the value of doing something to the cost of doing it is the most common calculus for Return on Investment (ROI), employed by many tasked with the prioritisation of work. The goal of this is to determine the margin of value for various endeavours and prioritise them accordingly. This usually looks something like this:

Return on Investment = Benefit ÷ Cost

Benefit is the expected return (e.g., a new feature will bring $200,000 of new revenue) and Cost is the amount that must be invested to achieve the expected return (e.g., 15 hours of work at $100 per hour is $1,500).

While this seems like a pretty reasonable and logical way to calculate the value of doing something, it comes with the dangerous assumption that we actually know how much value we'll get from the initiative and how much it will cost. Assumptions around both expected value and effort required are usually wrong, often dramatically. The outputs of algorithms like this can lead you astray if the inputs are incorrect, making prioritisation based on this method an exercise in futility. This is why teams should factor confidence into their ROI estimations, recalculate and reflect on ROI estimates after work has been completed, and assemble around long-term areas of focus where multiple hypotheses can be tested.

A simple way to improve the algorithm for ROI is to include confidence as a factor. You can do this by simply polling the team on how confident they are in both their cost and benefit estimations. This new algorithm might look something like this:

Return on Investment = ((Benefit × Confidence in the Solution) ÷ Cost) × Confidence in the Estimated Effort

This new equation is tempered by the confidence of the team, who might vote on confidence at the same time as they estimate the size of the work involved. We're penalising the expected benefit of doing the work with our confidence that the solution will bring the expected benefit (e.g., if we are 50% sure our solution will bring us the expected $200,000 of new revenue, we lower our expectations to $100,000). We are also penalising the entire ROI by our confidence in our estimate of effort. There is no single right way of doing this and you might want to tweak the algorithm to penalise the expected ROI in different ways.

By factoring confidence into our estimates of ROI, initiatives with a higher level of confidence are more likely to be prioritised over initiatives where the solution might need more exploration and the expected return needs to be better scrutinised. Highly effective teams will bring forward research and investigation (e.g., spikes) to improve their confidence in future work, before committing to risky initiatives packed with untested assumptions. Sometimes, teams might still decide to tackle work that they have low-confidence estimates for. Confidence factors are still useful in these scenarios because they provide a tool for teams to manage stakeholder expectations (i.e., we know we're taking a big risk here, but we think it is worth it).

Reflection is another valuable tool for teams looking to estimate ROI. Even seasoned teams can find it very difficult to estimate ROI in advance. Predicting the future is very difficult, and our best tool for improving our ability to do so is the retrospective. This is why it can be valuable for teams to re-estimate ROI after an initiative has been completed and the benefit and effort inputs are known. Regularly reflecting on whether a solution worked and what made our assumptions around value and cost accurate or inaccurate will make future estimates more reliable, even if only by better tuning our confidence in our estimates.

After a few cycles of estimating both value and effort, and reflecting on actual outcomes, many teams come to a common conclusion: big problems are rarely solvable through a single chunk of effort. This is why long-lived teams that are consistently focused on owning areas of improvement for the long term are usually the most successful. This is an alternative to bouncing between unrelated projects that attempt to solve diverse problems, which may only ever provide a degree of success, and is one major reason why hyper-focused products tend to win. Many solutions to one big problem trumps many solutions to many problems, because the cost of failure is lower and the compounding value of effort invested is more easily realised.

Is your product trying to be too much for too many people? By honing in on a more opinionated approach to the problems you solve, you might find it significantly easier to prioritise your roadmap, deliver software, and sell your solution.

While this is a word that often comes with negative connotations, I believe that great products, particularly in the B2B world, are usually very opinionated. They come with a strong view of how they should be used, and how the problem they are solving should be solved. These products differentiate themselves from the herd and disrupt incumbents by doing things differently. Many B2B SaaS products are simply automated workflows built from the opinionated views that you should solve that problem in this specific way.

There is a tension between this idea and the principle of building flexibility into your product and technology. Flexibility can enable you to more easily pivot your product direction and repurpose your technology, and strategically building your product in a flexible way can help you to maximise your options for the future. But, it can also severely limit the product you build by keeping you in a vacillating state. When building great products and technologies, there are many scenarios where you need to go all in. Otherwise, you end up trying to do too much for too many businesses.

This is especially true for the many SaaS products that require a degree of configuration or customisation (usually facilitated through professional services) during the onboarding phase. Many businesses building products like this encourage their prospects to come to them with a list of requirements that they will try to configure their product to satisfy. This usually leads to extreme diversity in how a product is used and configured, making the product expensive to support and slow to adopt. It also often leads to poor customer outcomes because it encourages users to configure the product in novel ways that the product was not designed around — just because something is feasible does not mean that it is desirable. Opinionated products are sold differently — they know what problems they solve, and they are opinionated about how they solve them. Customers are encouraged to bring problems to the vendor (not preconceived solutions or feature requests), and the vendor provides opinionated solutions to these problems. Sales teams confidently pitch these solutions as the best way to meet customer needs. The effort required to implement the product is low because it has been done before and the entire process can be either automated or templated. Novel solutions are avoided, and customers who need something custom go elsewhere. This standardisation of user experience and configuration is what makes so many B2B SaaS companies so valuable: they can achieve very good gross margins by selling the same solution to many businesses.

Much of this comes down to one of the major differences between professional services businesses and product businesses. While professional services businesses are building custom solutions to solve problems for their clients, product companies are building a single solution for a large swathe of the market. The one-size-fits-all approach is what makes product companies so much more valuable than professional services companies because this model is much more scalable. If you look under the hood of many B2B SaaS companies, they actually look a lot more like professional services companies that've built a degree of standardisation into their solutions through some product development. Many still have long sales cycles, diverse and complex implementations for each unique customer, and poor gross margins for their recurring revenue (i.e., they depend too heavily on implementation/professional services revenue and the recurring revenue side of their business is not self-sustaining). An over reliance on professional services often causes a bottleneck in the onboarding process, which stunts the growth of the company.

This might sound like an environment where sales teams are saying no to customers a lot more than they are saying yes, but opinionated products are actually easier to sell. Great B2B products come with their own philosophy on how big problems should be addressed. Philosophies are easier to communicate and spread around organisations and markets than feature lists are. Salespeople typically find it a lot easier to understand and sing from this type of solution-focused hymn book, rather than a checklist of features, and they become trusted advisors in the eyes of prospects. And, when selling a product with a specific worldview and differentiated approach, it's a lot easier for sales and marketing teams to challenge competitors. Challenger brands aren't better because of specific features but rather the broader approach they take: they are better because they do things differently (e.g., Notion has a great page challenging incumbent Confluence). Great products can become synonymous with the philosophies they espouse, even becoming movements (e.g., Roam Research comes to mind as a great example of a product that is synonymous with the movement it is currently spearheading).

Another benefit of building an opinionated product that supports a limited set of use cases is the technical simplicity that comes with this. Every configuration option that you introduce into the product introduces technical complexity. It is a lot slower for developers to commit new code products with a large number of configuration options and use cases. Automated testing is more difficult, and edge cases grow exponentially as you add configuration options. Ultimately, customisable software is slower to develop and harder to maintain in the long term.

A trend I've noticed amongst the most effective people I know is that many of them are keeping a personal knowledge base (which you could also call a personal wiki, a professional journal, or many other things). This is clearly a trend beyond my immediate network, given the glut of new tools at least partially designed with this purpose in mind (e.g., Notion, Craft, Clover, Roam Research, or Obsidian). I started my personal knowledge base in 2010 (using Evernote) and it has been incredibly valuable to me throughout my career, so it has been great to see this trend take off recently.

People have always taken notes at work — this is not new. What is catching on, though, is the idea of creating, revising/maintaining, and structuring these documents with long-term utility in mind. For most people, the notes they take throughout their careers are intended for temporary use (e.g., to ensure you don't forget decisions made in a meeting). My peers in the personal wiki club are creating long-lived documents on topics, and playbooks for situations, that will come up again in the future. Notably, they put effort into making them easy to rediscover and maintain.

Work is repetitive. Between days, weeks, projects, and jobs, most people will tackle the same, or very similar, problems and tasks multiple times. In the professional services industry, service providers embrace standardisation to improve the ROI of their work. For example, agencies tasked with building e-commerce websites rarely start from scratch — they bolster their process with templates and reusable snippets of code that reduce the need to re-invent the wheel every time they tackle a similar project. Professionals should think about their jobs this way: as an individual providing a service to a client (i.e., your current employer). If you are frequently carrying out similar tasks across different projects, it is common sense to standardise (and potentially automate) this work. By creating and maintaining personal documentation on the various problems you've tackled, you can build a playbook for the next time you have to tackle a similar problem. These playbooks should follow you for your entire career. The secret sauce for your effectiveness and success.

Throughout its lifecycle, a company typically builds value in its revenue, partnerships, employee base and intellectual property, and all of these aspects are reflected in its valuation. Throughout your career, the value of your labour will also increase. This is due to the accrual of value in your experience, your network, and aspects of your professional identity. Experience will give you more knowledge and better intuitions for what to do in various situations, and keeping a personal knowledge base makes your experience much more tangible, explicit, and accessible. This will make you a more valuable employee. You could think of your knowledge base as the intellectual property that you build throughout your career†. People with privileged and well-documented experiences could have a highly valuable knowledge base that makes future success more attainable.

Additionally, while it may be a little too cliche to bother pointing out, writing is a critical part of the learning process. Honing in on a specific opinion on a topic is most easily done through writing, and this process will help you to fully understand what you are learning. One added bonus of this: learnings and ideas that are solidified in text are much more easily shared. If you're trying to understand something complex, I suggest you try by writing an explainer for yourself, and keep it somewhere you can easily access in case you learn more, change your mind, or need to tackle this problem again. Every year, I write a new summary of my approach to product development. This helps me to solidify my ever-evolving learnings and philosophies towards what I do.

† The contents of your knowledge base should be your intellectual property (IP), not the IP of any of your employers. Don't keep data that does not belong to you.

Thanks to artists like Beeple and projects like CryptoPunks, NFTs have been the main character of crypto news in 2021. This has led to an avalanche of NFT sales by artists and celebrities all over the world. Despite the heavy focus on people with clout cashing in on their social capital, I think NFTs will have an even bigger impact on artists emerging today.

NFTs (non-fungible token) at a glance:

• NFTs are entries of data stored on a blockchain.
• The tokens that store data like this are therefore unique and non-fungible.
  • Traditionally, tokens (i.e., coins) on blockchains have been fungible (i.e, interchangeable). So, they work like currency, where there is no meaningful difference between two different notes of the same denomination. There's no value difference between owning two different individual Bitcoins.
  • Because data is stored within a non-fungible token, they are not interchangeable with other tokens — they are unique! There could be a significant value difference between two non-fungible tokens.

One common criticism of NFTs is that, as they are simply data in a public database (albeit a new type of database), they can easily be copied, reproduced, and created without permission. Why would you buy something anyone can copy? People making this criticism are missing the value of NFTs entirely. NFTs are more comparable to a certificate of ownership and authenticity than they are to a physical piece of art. When buying a Rothko, art collectors do not lament how easily they could be reproduced. This is because the value of owning a Rothko is not because it looks like a Rothko, but rather because it is (provably) a Rothko! Through NFTs, blockchains provide a more robust record of ownership than ever before (there is no reason why NFTs couldn't be used to represent ownership for physical art, too). Meanwhile, reproducibility will inevitably only get easier as the world becomes more digital — this makes a reliable record of ownership even more valuable, not less.

A thriving art market, with proof of ownership bestowed by trusted marketplaces, has existed for a very long time. On the surface, the technology behind NFTs may seem like an incremental improvement to this system. In my view, NFTs have already significantly changed the future of the art market, though. They've done this by making the ledger of art ownership available to artists no matter their career stage, rather than just those who can draw the attention of the likes of Sotheby's. This means collectors can invest in artists from all over the world at the start of their careers rather than only after they make it big. This new market of early-career (and therefore cheap) art also opens the collector market to anyone.

The ability to easily and safely find and purchase art from artists who are only just starting their careers is creating a huge opportunity for collectors of all calibres. By investing in an artist at the start of their career, you can achieve much more ambitious long-term capital gains than ever before. Taking a risk on an emerging artist could eventually pay off massively. This essentially creates an angel investing market for art and culture. This angel investing market will strongly favour those with a good eye for what will eventually become very successful, which probably means other artists. This will empower artists to become art collectors, reinvesting the capital they've made from their art, into the next generation of artists. This will look a lot like the world of startup angel investing.

Essentially, the world of art investment will look much less like the ultra-rich investing in already-famous artworks, and more like everyday people and artists re-investing their capital in the next generation of artists. The ultra-rich will continue to acquire their fair share, of course.

Lastly, another feature of blockchains is that they are programmable. This means new rules can be built into blockchain-powered markets. Artists choose where they sell their work, so they can choose a rule set that looks out for them. For example, OpenSea (like many other NFT marketplaces) allows artists to configure royalties when creating their NFTs. NFTs with royalties configured will pay a commission for any future sale to the original artist. This means if you sell your artwork for a small amount today and later become very successful, you'll continue to earn royalties from future sales of your now highly sought after artwork. This, and other future marketplace innovations, will create a more artist-friendly market.