For people who work on Security, Abuse, Quality, Infra etc (Inverted products) success is: nothing happens. This world of inverted products is very different from “normal products”. In this post I use the Product Pyramid as a fresh way to highlight how products in security, abuse etc are different from normal products. #NAIWU

#NAIWU: No AI Was Used in writing this post.

The Product Pyramid

Precedent

In this step we basically consider how the user is solving their problem before the product was even launched. See this post for more details

Normal Products: We consider the current steps / processes / apps / solutions the user is using before we’ve built ours. We use this information to find pain points and make sure that the user has a benefit from using our new product over their existing solution. 

Inverted Products: Here we are basically targeting abusers and criminals. How are they currently attacking our users and creating benefits off of the misery of others? This will help us design our defenses later. If we know that attackers target users to get their passport number for example, we can use this to protect the same sensitive information very well inside our product. In our case we ensure that getting to the same sensitive information is harder in our product than it is in whatever way they are getting it now. Also if we can understand how attackers are doing damage now, we can use that to identify signals to find them in our products as we potentially open new ways to do damage.  

Person

In this step we think about who we are building / managing our product for. What kind of person will use it, or perhaps it’s a system that will call our product. See this post for more details.

Normal products: For normal products, this is the user. What characteristics do they have that might help us build a better product? An app for kids would look very different from an app for adults for example. As product manager, you want to help the user on their CUJ, make a purchase, send an email, watch a video etc. You want to make sure that the product you choose to build matches the characteristics of the types of people that will use it.. 

Inverted products: We focus on the attacker, the abuser or malicious actor. We want to try and really put ourselves into the shoes of this person and understand them and their motives. This can help us decide on which defenses to use later. For example, if we know the attacker has financial constraints we can perhaps use this to our advantage later when we design defenses by making attacks more expensive.  In contrast to the normal user, you  don’t want to keep the attacker in their CUJ, you want to stop the attacker in their CAJ. Stop them from achieving their goal

Problem

In this step we examine the problem the user (Person) has that we want to solve for them. See this post for more details.

Normal Products: This would be the normal  problem you would try to solve. Like being entertained, achieving a transaction, finding information, getting advice, planning, productivity, connecting with other people etc. Really understanding the user’s main problem helps us build the best product for them. 

Inverted Products: Now we have to solve for the attacker, their problem is different. They need to get some kind of value out of the attack they are doing on your user or platform. Eventually this is either mischief or financially/politically motivated. The problem is to extract this value. As with the “person” step, If you understand the problem your attacker is solving you can build better defenses. Is the attacker trying to gain fame? Trying to feed their family through criminal activity? Trying to fulfill a political goal? All of these would require different actions and thus different defenses. 

Product

In this step we decide the solution to the Problem that our Person has. This can be an app, a website, a service or a physical product. It is not always a mobile app ;-). See this post for more details.

Normal Products: This could be any kind of app, site, or AI agent. It could also be a physical product or service. It brings together the Person and the Problem and meets them where they can best solve it.

Inverted Products: In this case it could be an invisible defense system (detection, mitigation, prevention). It could also be a standalone security product that protects an organization. It could also be a simple smaller defensive feature in one of your products. The most important thing here is to use your complete knowledge of the attacker and their motives to decide the right solution. Do you just need to introduce a time delay or perhaps build a complete block? Do you simply need to inject “cost” or is there really no room for error and you need to focus on complete prevention. All of these will contribute to deciding where you build your product. You also need to think about whether it’s best to build directly for the person or it’s better to build an intermediate product that someone else can embed in their user facing app. Inverted products can be complex like that. 

Parts (Features)

Once you’ve decided on the product you will build, you will pick its smaller parts, its features. Here you use your knowledge of the Person and the Problem to further define your product. See this post for more details.

There is no big distinction between normal and inverted products here. In both cases you keep the Person/Problem as a north star and define features that will allow you to get as close as possible to your goal of helping your user solve their problem (normal products) or preventing your attackers from solving their problems (inverted) 

Performance (Metrics)

Once you’ve defined the product and its parts you need to define how you will measure success. See this post for more details.

Normal Products: For these, you can look at the metrics that indicate whether or not users are able to solve their problems in your product (clicks, transactions, interactions and other funnel metrics). You can also look at revenue or other business metrics. 

Inverted Products: In the inverted case this is probably the most complex part of the product pyramid. It’s very hard to measure how successful your product was in disallowing attackers to solve their problems. Like how many bad image uploads did you prevent, or how many account takeovers did you prevent. This type of data is not easy to obtain and full of edge cases and intricacies that requires it to be presented with a story (more about this in this blog post about damage). Inverted metrics suffer from the “Invisible line” challenge. However, the fact that it’s different doesn’t release us from the obligation to try. You can at least measure the badness that still gets through and steer on that. Badness might be hard to qualify, but things like revenue or user engagement lost can be good starting points. 

Publish (Launch)

Once you’ve defined all your product, you need to think about how to bring it to market, which channels etc. See this post for more details.

Normal Products: For normal products you would think about where your users “live” and how you can reach them with your product whilst highlighting the benefits your users will get. You would do a blog post, launch announcement, in product banner, conference presentation, partnership or something else to try and get as many people as possible to use it. 

Inverted Products: For inverted products you want to make sure that your target group (the attackers) are never aware that the product exists until it’s too late and they get caught. You don’t want to publicize it at all but still get it in the way of every single attacker you know about. 

Pilot (manage)

Finally once the product is launched you want to keep developing it. See this post for more details.

Normal Products: Here you observe your previously defined metrics and tweak to better serve your user needs. You will launch new features, tweak existing ones, expand into new markets etc.

Inverted Products: For inverted products it’s similar, you constantly evolve how well your defense or inverted product works. You keep checking precision / recall and the damage that still remains after your defenses. There isn’t really anything like finding new markets in the traditional sense, but seeking new badness to stop with your solution will help make your environment better. Perhaps that reAuth solution you developed can also protect other things in your app than just the sensitive data you built it for. In this stage it’s also important to communicate a lot with stakeholders. Since Inverted Products suffer from a lot of misconception, we need to constantly communicate about them. This will help keep stakeholders aware of the importance of our product and the benefit it brings. If you are selling an inverted product then it’s even more vital to keep telling your customers about all the good you are doing for them. 

Conclusion.

Working with, selling, marketing or building inverted products is different. Using the Product Pyramid is a fresh angle to look at your inverted product and make sure that you’ve considered all angles and haven’t missed an opportunity to expand the success of your product. Because after all, if your product is successful there will be less badness in the world: less bad content, fewer outages, fewer bad AI responses, and… fewer people hacked. 

Because remember: saving one is worth it

#NAIWU: No AI Was Used

I used no AI in writing this post. Every word you see on this post is my own. I didn’t even ask an AI to check or re-write things (unless you count Google docs spell check ;-). 

Yes it took longer to write this post and some might feel that that’s a waste of time. But I don’t write these to “chunk out content”. These writings help me think, make me a better PM and help me form concepts. I would say this entire blog is more for myself than for the world.

Of course I hope my posts are helpful for others (and I occasionally receive amazing encouraging messages) . But for now these blog posts help me most of all and so I didn’t use AI at all in writing this post. 

I don’t add this to brag but more to encourage anyone to make the same tradeoff. 

Perhaps in future posts I will use AI but if I don’t then I will add the #NAIWU hashtag again (I won’t go back and update all my blogposts retroactively 😃).