Customers of SaaS products are accustomed to industry standard functionality, and our product needs to reflect that.
Industry standard is one of the biggest hoaxes of the software development world. Telling me that a solution is industry standard is like an infomercial telling me that 9/10 dentists recommend a toothpaste brand - they are both based on fictional authorities, and not data.
There is nothing wrong about following industry standards as a concept. Especially in the world of SaaS (Software as a Service), users are indeed used to products functioning a certain way, and any deviation is met with criticism, annoyance, and resentment. Changing checkboxes to only allow one option does not make you innovative, it makes you a bad designer. But I do not mean to dwell on the dichotomy of adhering to norms versus fostering innovation. What I want to focus on is how often people misuse the term ‘industry standard’ in order to impose a false sense of authority backing their decision or idea, and what you - the product engineer - can do about it.
What is ‘industry standard’?
The phrase industry standard refers to an established practice or implementation in a particular industry. It can be formal and officially enforced by a regulatory body such as the security ISO-27001 standard, or something colloquially accepted like QWERTY keyboards.
In SaaS, most standards are informal. There are certain features such cross-application identity management which are more formalized via specifications the likes of SCIM (System for Cross-domain Identity Management), but for the most part products have custom implementations. To get an idea of how something should be done, product teams look to other established SaaS platforms of enterprise giants like Microsoft or Google Workspace.
Why do we desperately want to follow industry standard practices?
For one - it’s easy. Coming up with a product solution that will answer the current customer requirements, or even worse, predict all possible future requirements they might have is very hard. But if we look at what others before us have done, we can leverage their trial and error and immediately offer a relatively mature feature that provides value.
Second - it’s what customers expect. With so many different tools on the market, it can be overwhelming to learn the ins and outs of all of them, especially if you are an IT admin at a big corporation. Imagine if every different device you had to use had a different keyboard layout. That would suck right? Well that’s the exact pain your customers are feeling. And unhappy customers are a churn risk.
And in here lies the hoax
Now that we’re aligned on what industry standard is, and why following it is important, we can understand why the statement - Customers of SaaS products are accustomed to industry standard functionality, and our product needs to reflect that. - carries so much weight. I mean it’s only logical that we want to follow industry standard approaches.
But if I told you Rust is the fastest programming language - would you take my word for it and redo your entire codebase, or ask to see some benchmarks? For the sake of both of our careers, I hope it’s the latter - and you should apply the same standard to product decisions. If someone comes to you with an ‘industry standard’ solution, they should also bring receipts to back it up, and you should be able to review it thoroughly.
Otherwise, they’re just using a loaded definition to avoid a discussion and slide their decision forward.
How do you tell if you’re really dealing with ‘industry standard’?
As engineers, we’re often challenged on our technical decisions. This happens throughout the whole process, starting from the original technical design, and following into the code review phase. People making product decisions have their own feedback loops, they often do not have the same type of peers as engineers. The people with enough context on the specific product area are usually the engineering manager - or the product engineers themselves. So, when a product manager - or anyone really - comes up with a solution they are marketing as ‘industry standard’ you need to try to understand if that really is the case.
Step 1: Look for more examples
When someone describes a solution as standard, they usually have other industry examples to compare to. The best product managers I’ve worked with thoroughly analyze the market, explore multiple solutions, and clearly communicate their preferred direction based on product fit. But many tend to only point out examples that confirm their biases. This is not always intentional. In the same manner engineers may flock to technologies they’re comfortable with, so can product managers to patterns they’re familiar with. Or perhaps it was a domain they’re not familiar with, and they went with the first example they found.
Sometimes people flock to the big players as a symbol of authority for proper tech and product design, and for good reason. Companies such as Google have the resources for research an development and plenty of iteration, leading them to the right solutions. But if you have a look at the Google graveyard, you will see that the industry giants also make mistakes.
By pointing out other alternatives in the industry, you challenge the proposer to consider other options. This forces them to either defend their decisions appropriately, giving you confidence that whatever you implement will fit customers’ expectations, or to consider a pattern that fits better.
Step 2: Focus on your industry
SaaS as a whole is too broad. While a solution may be industry standard for some product categories, it may be the exact opposite in others. For years, the prevailing licensing model in SaaS was to pay a fixed fee license for the software and use it without any limitation, barring hardware limits or fair use clauses. With AI (Artificial Intelligence) into the mix this is no longer financially viable for providers, which is why subscribers usually get a limit on monthly credits, or pay per credit.
In order to make sure you’re building the right product, you need to look for examples from the specific product category your tool fits. If you are an engineer at Snowflake , a cloud data warehouse solution, what other similar companies like Databricks or Datadog are doing is much more relevant than what Figma, a product for designers, is. But if your product manager comes from Figma, they may be inclined to implement similar patterns at Snowflake - resulting in missed requirements and poor functionality.
So, at Step 2, repeat the same exercise as Step 1, but focus on products similar to yours.
Step 3: Evaluate product fit
So you went through Steps 1 & 2, and it indeed looks you’re dealing with a proper industry standard approach. But how does it fit your specific product?
The problem with industry standard solutions is that they often require industry standard products. If you are dealing with a product that has accumulated a decade of technical and product debt by incorporating various workarounds, making one part of it adhere to industry standard, may require significant reworks elsewhere. This would not only require significantly more time to implement, but also force you to align with different teams, allocate resources, and a ton more complexity.
Think about a simple electrical appliance. If you look at a toaster designed and sold in Europe, and use it as an inspiration to build your own version to sell in the US, you will soon face a pretty big issue - the voltage difference of the electrical power grids between the regions. While it may be the perfect toaster, if it’s designed to work at 220v, it will take significant efforts to adapt it to a 110v grid. The same can be applied to solutions for SaaS products, what works perfectly for some, may be headache to implement for others.
It’s important to share such complexities with your product manager and ask them to consider other patterns that may fit your product better. At the end of the day, this is your area of expertise, and your product manager counts on your judgment. You may even be able to suggest a preliminary implementation that can eventually evolve to the vision they have. After all - you’re working for the same company and this is a team effort.
Ultimately the goal is to deliver customer value, and there’s no point trying to achieve an industry standard solution if customers never get to use it.
Step 4: You’re done
That’s it. All you need are those three steps! This guide is aimed at you - the product engineer - and not product managers or product designers. The idea isn’t that you need to do extensive market research, customer interviews, surveys, or design validation with focus groups — although don’t be just an armchair critic; make sure to include your suggestions and feedback in a document you can share with the team.
The main point is that you should be able to understand why the team and product is moving in a certain direction, whether that really is the right way forward, and be that sanity check for your PM to also give them confidence the solution will be a success. At least as far as you can tell. No one has a crystal ball.
While you may feel you are just in the passenger seat when it comes to product decisions and cannot do much to steer the car, you can at least still do your part and make sure the decision maker does not fall asleep at the wheel!
And if they are still not convinced?
This can indeed happen. It could be due to company culture, or ego. Or you could just be wrong yourself!
If you very strongly believe that your team is going in a very wrong direction, you can try to raise with other stakeholders in a more formal manner. Try to have an honest conversation with your engineering manager and they might help you get your point across better. Or at the very least they’ll put you at ease that the chosen direction will not lead to disaster!
Remember to not dwell too much on it. At the end of the day, the only thing worse than a bad decision is no decision. So disagree, commit, and do your best to resist the urge to unleash the snarky “told you so” when the universe finally validates you. Yes, even if you’ve been rehearsing it in the shower for weeks.