Product-led is not just a go-to-market strategy, it affects how you manage your entire business pipeline, and can have a massive impact on your development process, team, and of course – architecture.
Hello, everyone, and welcome to today’s webinar presentation, “How to Turn Your App into Your Best Salesperson,” brought to you by Frontegg. Before we get started, I have a few housekeeping items I need to go over. First, if you have any questions for our presenters today, please post those in the Q&A section and we’ll get to them after the presentation. If you experience any technical difficulties today, please post a message in the chat panel and I will work with you to resolve those issues.
Last on my housekeeping list. Today’s presentation is being recorded, and it will be available shortly after the webinar ends. Now that we are through with the housekeeping items, I would like to introduce our presenters. First, we have Aviad. He has been a developer for the last 20 years. He held a few management and architecture positions on startups such as Vicon and HTS, as well as in larger companies such as NICE and Check Point.
Today at Frontegg, Aviad works closely with many customers to help them build their SaaS solutions. Now, Stav. Stav is experienced in product management with a focus on SaaS B2B products. She’s a professional in transitioning companies from sales-led to product-led structures, which allows them to grow fast and support multiple sales channels.
Today, Stav is also a mentor for product managers and founders who are looking to build products that sell themselves in the B2B area. Now, without any further ado, I will turn it over to our presenters.
Hi, Aviad.
Hi, Stav.
So thank you for coming to this important kickoff meeting. Today I want to talk to you about the most important initiative we have for the company this year, which is how to turn our app into the best salesperson.
Well, what do you mean the best…we already have salesperson.
Yeah, I know we have salesperson and they’re great, but let me ask you something. Like, how do you feel when someone is trying to sell you something or write you a LinkedIn message and trying to tell you about a new service that they want you to buy? How does it make you feel?
So, you know, I get, like, few of this every day, and usually, like, I turn them down. I don’t take such calls.
Wow. Every day is a lot. And, like, what makes you listen to someone or want to buy a specific service?
So normally, I prefer to talk to someone right after I can experience the product myself. So I like to free trial into the product, and then I’m willing to talk to someone.
Great. So this is exactly the reason. I want us to do these important initiatives because most of the people like to try before they buy. They don’t want to talk to a salesperson. They want to experience value by themself. And this is why we have to convince customer to pay for the service before they’re talking to someone.
Look at the best-growing companies, the best PLG companies. They all allow you to try something, to experience the value, and only after you understand the value and you have an intent to purchase, you’re talking to a salesperson.
But PLG, you said or… What is… Is it, like, a new technology?
No, Aviad, it’s not a new technology. PLG is a product-led growth. It’s an end-user-focused growth model that relies on the product itself as a primary driver for customer requisition, conversion, and expansion. Actually, studies show that product-led companies grow 30% faster.
All right, 30%. You got me at 30%. So you got me in. What do I have to do?
Okay, great. So I want to start by just, like, letting you know what the discovery I did in order to understand what are the main things we need to do? So I looked at the best salesperson and I tried to understand what makes them so good. Like, what are the skills that they have that we have to replicate in our product? The second thing, I look at the PLG growing companies, the best companies today that already succeed in turning their product to the best salesperson and what is common to all of them.
And after gathering all this information, I’ve come with the top three elements that we have to do in order to turn our product to the best salesperson. And what I want us to do today is to cover the three of them to understand what we need to do, and then to understand from you what are the technical needs from…the technical aspects, everything we need to do, what are the risk?
What are the best practices? And that’s it.
Okay. Sounds good. Let’s go.
Great. Let’s start. So the first thing we need to do is a best salesperson, first of all, is delightful. He has a great positive first impression. And this is something we also need to establish in our product. We need to… A good salesperson is someone that you want to listen to him.
He looks like a trusted person. He makes people, like, want to look at him, listen to him, everything. So we have to make our product the same. And the first thing we have in our product, the first first impression is a signup form. Sixty-nine percent of people form a first impression of someone before they even have a chance to speak to them.
This is exactly the signup form. Before you experience a value or know something about the product, you first need to fill the signup form. So the first thing we need to do is to remove the password from our signup form. Aviad, listen, like, this creates so many friction in the process, and studies show that, like, removing and moving to passwordless, it can improve our signup rate in more than 44%.
So what do we need to do?
So maybe we start with few questions on, you know, what exactly do you mean by signing up and passwordless? So, you know, there are some factors that we need to take into consideration. For example, what is the unique identifier you want to keep for your users? Do you want to store emails? Do you want to store phone numbers?
Do I need to choose, like, only one?
So I’ll tell you that. I mean, emails can walk through all the other systems as well, where… You know, phone numbers is a bit more intrusive. People don’t like to hand out phone numbers. I suggest we start by email because that’s, like, the B2B common practice, and then providing a user to add phone number in the future.
And when you talk about passwordless, what kind of passwordless method do you want to go? There are two, like, common flows around one-time code or magic link. And obviously, do you want to support SSO as well, like log in with Google, log in with GitHub?
What is the one-time code? What is the difference between the one-time code and magic link?
So the one-time code basically means that you are providing your email. You click on send me a code, I’m going to send you a code through your email address, and you’re going to input that on the next string. Where with magic link, I’m going to send you a code through magic link. You’re going to press on the magic link, and it’s probably going to open on a new tab.
Wait. But if I, like, send you a link, a magic link, can I pass this link to other users, and then users that I didn’t invite can enter my system?
Yeah. So that’s a great question. So that exactly brings me to my next question. I suggested we enforce that the same device that you ask the code or the link on will be the device that you’re using it. So that will be like a best security practice to make sure that you’re not…like, the link is not sent to another device.
But it sounds like it’s like for the experience is not so comfortable because if I’m, for example, getting the link and I open the link from my email and it’s automatically open, like, a default browser that is not the current browser that I’m using, so it might frustrate the…it frustrates the user, you know.
Correct. So this is why I think one-time code will be best for user experience in this scenario.
So when I’m getting the code and I’m not getting out of the app.
That’s correct. And then we need to decide, so what is the expiration of the code? So how long do you have in order to input the code? You know, shorter codes are better for security, shorter expirations are better for security, where longer expiration is better for UX, but it’s damaged security.
What is the best practice based on your knowledge?
I would go with probably around up to five minutes, not longer than that. It gives, like, the user enough time to go to the phone to look for the code, even to be distracted for a second, and yet, like, develop on the UX side if they input, like, a code which is expired to let them ask for a new code.
Okay. Sounds great.
And when we talk about SSO, so what SSO providers…because that’s another part that you wanted to talk about, the log in with Google, log in with GitHub. What SSO providers do you want to support?
So first, I love SSO social login. I think it’s best in everything related to user experience because in one click you immediately get into the product and you also don’t feel you need to provide extra personal information to a vendor you know nothing about. So I love it, but I think, like, we need to have between two to four social logins, not more because it’s confusing for the user.
So I’ve checked what are the most common third-party services our users usually use, and I think, like, Google, and GitHub, and Microsoft is the best ones that everyone have, and we need to use them as a social login.
Perfect. Cool. So we will take on that ones. And in terms of scoping, so normally we ask for email and password. Is, like, any other scopes that you want to ask on the overflow?
What do you mean by scope?
I don’t know. For example, if you’re logging in with Google, you can ask for a list of contacts or, like, access to the calendar. I would advise, by the way, on the signup screen against it because that kind of frighten the user who knows nothing about the product. So maybe if you need that, we can do it later, but that’s…
Yeah, I agree. I think, like, let’s minimize the things that we want from the user in the first step. Maybe after that when we need to…for example, we ask him to invite users or something like that, we can connect to his contacts or something.
Perfect. Cool. And the last question on this SSO part. Normally when you do log in with Google on Google Chrome, now there’s a new experience out there which is called One Tap. And that allows, like, because Google Chrome is very popular and log in with Google is very popular, that allows a one-click login without redirect or without popups.
Is that something that you want us to support?
Love it. Great. Yeah, I want it.
Cool. So we’ll edit into the timeline as well. So if I think about the takeaways from this one. So we’re going to implement emails as the unique identifier. That’s probably the best practice for SaaS applications, B2B applications. Passwordless basic implementation is going to do through one-time code for better UX. We’re going to verify the same device for security purposes.
We’re going to implement privacy first and choose only email and profile as the scopes for this. And we’re going to throw in a One Tap log-in to make sure that our Google Chrome users can log in quicker.
Perfect. Sounds great. So Aviad, there is another thing I want in order to make our product, our signup form delightful. I want us to create powerful design and copy because, like, some things that when someone is coming to our signup form, he also needs to understand why he should start a signup.
What is in it for him? What is the value? So I want us to build, like, a marketing section inside the signup form, but a place where the marketing can change what is right there or images or something but with no code. We don’t want them to be dependent on the developer’s team.
So I want something like that. Like, I prepare, like, a Figma, which I have in one place a signup form, but in the next place I have one customers are telling why he should work with our solution and also logos of our solution.
And I want the marketing to be able to change the text all the time. I don’t want it to be, like, something that is sticky.
Okay, sounds good. So a few questions on this. Which resolution do you want to support for this, and which devices? Is it, like, mobile? What kind of resolution do you want to support?
So great question. My UX designer will provide you, like, exactly the screen resolution, which the split is relevant, but for mobile, we’ll only work with the form, the signup form. But for a larger screen, we can work with a split signup design.
Cool. And how about motions? Do you want to support, like, motions of disappearing and not disappearing maybe?
Yeah, I love motions, but we need to be really careful with that because we need to do it right that it will not, like, be annoying to the user, and also doesn’t it affect, like, the performance, like, the load time of the page.
Yes. So that brings me to…you know, that brings a whole set of questions on if we can think about we want to have marketing full control on the content. So, you know, marketing are not developers, so they can maybe destroy the entire load of the page with bad HTML.
How about providing them with some templates approved by developers for that content?
Yeah, I think you can go with that. Like, we can have, like, between two to three templates.
Cool.
And we want to provide them, like, remote access to the content, right? So we don’t want the developer within the flow.
No. I want it to be super fast and lean process.
And so if I think about my takeaways from this one is that obviously I’m going to use CSS breakpoints to allow this mobile responsiveness. The developers like to use REM on pixels, and we’re going to minimize the number of animations that we’re going to use to improve the load of the page.
And working with marketing, we’re going to build a CMS approach that they can inject the templates. And we’re going to monitor the page load through heavy images and bad HTML so we know how to fix that writing time.
Great. It’s great. So Aviad, after we covered the first part, the delightful part, I want us to move to the attentive part. So I think one of the best skills that a good salesperson have is the ability to listen to people. They don’t treat everyone the same.
They understand that each user, each persona is unique and have his own needs in the product. And it’s really related also to the product itself and to the approach of looking at the business as not business to business but as business to human. Understands that each human has his own needs and want to experience a product in the way it’s convenient to him and not necessarily as the rest of the people in his organization or in other organization.
And users wants to do things by themselves. They don’t want to be dependent on you each time they want to change something in the settings. So I want to allow them self-customization, making the journey there, like, making inquiries, they decide how they want to experience a journey.
And also people that are really, really invested and make it personalized to them have much higher intent to convert in the end of the day. So I want us to create, like, a self-configuration in settings, an area where the user can set his privacy and security preference. For example, he can decide if he wants a multifactor authentication when he log into the system, if he want to log in with a fingerprint or he wants to log in with SMS.
He can invite users, assign roles, he can configure SSO to his organization, and he also can create webbooks, and start playing with a product and match it to his needs or adding integrations to other system by himself.
Makes sense?
Yeah, totally makes sense. We’ll take care of the privacy and security. I have few questions on the team management part where they invite your user. So do you want to allow each of the users to belong to one account? Like, we’re forming accounts, right, when we invite another user. Do you want each user to belong to one account or multiple accounts?
Wow, it’s a very good question. Actually, I need him to be related to multiple accounts because sometimes a user is, like, an outsource or a reseller or something, and he belongs to many accounts, not only to one. So yeah, I want the ability to invite him to more than one account, and that he can see from his dashboard that he can go between accounts, between different accounts after signing up.
Cool. Sounds good. And how about the actual invite? Is it like… Do you want to do it through email, or do you want to do it through a reusable link? For example, in Slack communities, there is a reusable link that everyone can join through. But it’s less secure.
With email, it’s, like, a one-time link that only the actual user can get and use only one time.
I really like the link option. I see it, like, in the best collaboration products. And I think it’s best. I’m a little bit concerned about the security. Like, can they share the link with others? Like, the link can go everywhere?
That’s the problem with reusable links. You can add, like, a certain level of mitigation on it, but I don’t know, expiration, 30 days, 7 days, 3 days, 1 hour, but still, I mean, there is a security issue over there.
Can I, for example, decide who are the users that can log into my system?
Yeah, so what we can do is maybe to limit, like, the access to specific domains that might wrap around it.
Okay.
Cool. And when we talk about sending over emails, I mean, which email compatibility do you want to support? Do you want to support a new web? I mean, I know from previous position I held, there was a real issue around sending emails through Outlook, you know, sending images, sending a bad-formed HTML.
This concern me. If I invite someone in the email, like, it has to be…it should support all type of emails because I don’t know what email providers the user is using.
Yeah. Cool. Best practice is not, you know, to send huge images and to use, like, well-formatted HTML. There are great tools to check email compatibility as well. So we can definitely walk around it. And we discussed the invitation token, so if we’re sending it by email, we’re probably going to leave up to one day for better mixture of security and UX, and they’re going to be used only once.
Cool. So if I collect all my takeaways from this team management, so we’re going to plan ahead, we’re going to keep… We’re going to build a user management system that can accommodate user into multiple accounts. And when we invite the user, we’re going to keep the invite link as one-time. We’re going to reduce the risk of letting the same link be used again and again.
And we’re going to think about email compatibility. We’re going to take into considerations, like, all clients, like Outlook, etc., and we are going to keep the invite link long enough but still short to have a best mixture of security and UX.
Cool. And you talked a little bit, Stav, about authorization and role management. So I have few questions on this as well. Do you know how many roles you’re going to have within the year in the product?
Currently, I have a closed list of three roles, but it will definitely change in the future. Like, I believe it will have more and more roles. And actually, specific customer might ask for a specific role that we don’t have today.
Okay. Okay. So that means that the role probably is going to be an open list. So that means that we’re probably going to map the list of permissions, right? I mean, we cannot support only roles.
Yeah.
And how about levels? For example, I mean, is an admin superior for an operator, which is superior for a viewer?
Why do I need it?
For security best practices. Obviously, we don’t want an operator being able to hand over an admin roles because there are operators. So if we’re taking, like, the self-service into the equation, providing an operator the ability to hand over admin roles basically causes roles elevation.
Okay. So yeah, we definitely need that.
Cool. So I need to think about that as well. So if I gather all of this into my takeaways, I probably going to plan ahead and allow each user to have multiple roles, and I’m going to protect my APIs, like, on the get-go to be protected based on permissions. And I’m going to do the mapping to roles and permissions in order to allow this flexible model of roles.
Even if we are not doing it on day one, we’re going to plan for levels. So we’re going to protect, like, roles elevation and we’re going to allow context on roles to provide this multi-account, multi-roles idea of permissioning.
Okay, great. Sounds like a lot of work and very complicated solution. But it’s necessary. The third thing and is the last thing that I want us to focus on is confident. So yeah, it might be obvious, but when you share information and close a contract with a vendor as a business, you need to trust the vendors that you’re closing a deal with.
And the salesperson should be someone that you really, really trust him, and you all the time try to ask him question to make sure he stands in the level of confidence that you need. Lack of trust is the main reason to lose a deal. Like, companies come with a checklist of security and compliance things, requirements that you must meet them.
And what I want us to do is, like, try to take this checklist of the B2B buyer and add it to the product. So when the buyer is starting to use, to try our product, you already get answers and, like, check marks or the things that he looked for in everything related to security and compliance. Makes sense?
Totally.
Great. So I know security is the best topic for you. So the first thing I want us to do is to increase trust during the signup process because when people come to sign up and share their private information, the email, or other information, this is a situation where they don’t know you at all.
They have a lower intent because they don’t know what they’re going to get. And this is the place that we have to remove any concerns in sign up to the process. There are three things that allow us to eliminate the fear of sign up to our product. The first one is to add the term of use and privacy policy to our signup form. The second one is to add reCAPTCHAs.
They need to see the reCAPTCHAs. They need to see that we are dealing with fraud and with bots. And also, in the CTA program, we have to tell them that you can start a free trial, but no credit card required. They don’t need to give us any information. I want it just, like, the email and nothing else so they easily can sign up to our system.
Cool. Sounds good. So, you know, I’m glad that you brought up reCAPTCHA. Personally, on any signup, I look for reCAPTCHA icon to make sure that, you know, it is bot-protected. Which kind of UX do you want to… There are a couple of types for reCAPTCHA, especially these days, where there’s the checkbox one, there’s the images one, and these days there’s the one that
The images when you click on things like you try to solve something?
Yeah, totally. There’s this one as well. And these days there’s the one that I preferably really like, which is the invisible one because, you know, there are a lot of information about how the reCAPTCHA with…you know, you fill this Lego or complete this image actually reduces the signup conversion.
So how about invisible reCAPTCHA?
But, like, how invisible reCAPTCHA works, like, how it…because when you ask the user so you check he’s real, how it works in the…
So invisible reCAPTCHA is actually kind of a magic where actually there is a score that is being collected through the reCAPTCHA engine and this score is basically the likelihood of you being a bot. But that poses another issue where if mistakably the reCAPTCHA engine detected you as bot, that means that you are not allowed to sign up and that causes another friction.
So we might want to think about doing the reCAPTCHA invisible. That will be great for, I don’t know, 95% of our users. And still, we might want to implement fallbacks in case that the user was identified as bot. Maybe we need to implement a fallback engine to make sure…
What does a fallback do, like, if I have a fallback?
For example, I mean, in case, you know, 95% of the users didn’t have to fill anything and then if the user is detected as a bot, we can do a checkbox, we can do, I don’t know, fire hoses, and that kind of stuff.
And about the terms of use, you mentioned that you want to have terms of use and privacy policy. Do you have, like, a final version, or, like, do you think it’s going to change frequently during the upcoming year too?
Yeah, so definitely it’s going to change because, like, based on the GDPR, like, the privacy policy is for sure going to change because every new third parties that we are working with, we need to update the privacy policy, and it changes all the time. So it needs to be…I want it to be changed with no code. I don’t want every time to open a Jira ticket to a developer to change the term of use.
Cool. So for the no-code part, I think we can go with the same approach that we had for the marketing stuff. But we need to plan ahead for this as well for the marketing content to consent that needs to be collected.
So if I think about my takeaways on this one, so I’m going to throw in an invisible reCAPTCHA with fallbacks. The terms of use and privacy policy. We’re going to do it, like, as a filter, we’re going to remove checkboxes and that kind of stuff. And because that’s probably going to change frequently, I’m going to throw into the user management solution a mechanism that will track which user signed up on which terms of service and privacy policy version.
So we might…you know, if we’re updating the versions, we send notification to the relevant users, and we’re going to build something that will be able to keep marketing consents based on location. For example, if the user came from the EU, they need to accept marketing consent. I know that we are not sending much now, but if that changes in the future, we’re going to build it into the signup as well.
Perfect. Okay, one more thing we need to do to create, like, trust and to be confident vendor is to uphold the right to be forgotten. This is something users that are sensitive for privacy, this is one of the first things that they will look in our product, the ability for them to delete themself and to ask us to delete every data about us. In many services, it’s really hard to do that.
Like, you need to contact someone and it takes time and no one answers you. I want it to be, like, really self-served. Like when I click on delete account it will make sure, it will ask me with a confirmation dialogue if I’m sure that I want to delete it. And after that, the data, the personal data of myself will be deleted.
Cool. So when you want to, like, provide the user the ability to delete themself, I’m sure it’s going to be for every logged-in user, right?
Mm-hmm.
Do you want to delete immediately? Do you want to give them, like, I don’t know, 30 days to…because that’s affect, like, what I’m doing. Like, hard delete or soft delete?
Yeah, I think we need to start with a soft delete and after 30 days to delete completely. Because I’m afraid there will be some mistakes with this button and we still need the ability to recover the data.
Cool. So we’re going to give 30 days and then they want us to delete all the relevant data. I don’t know, we have the support tools, we have the CRMs, we have logs, we have other stuff. Do you need to delete all the data from all the relevant systems as well?
This is a must. We have to delete every data, every personal information that’s related to the user. Also, if we’re using fourth party, like, the fourth party, every third party and fourth party that we are using, we must delete everything from the HubSpot, from the Mixpanel, from every service that we are using.
Okay. And how about adding another verification? Do you want to add another verification to this action? I know that, you know, in some of the cases, you’re required to have a specific role in order to delete an account.
Can I use, like, the multifactor authentication? Like, to use…
Yeah. Multifactor, super user mode. Yeah.
Yeah. I think the multifactor authentication here is super important.
Cool. So in terms of my takeaway from this one, I’m going to probably implement a soft delete, store the data for 30 days. We’re going to issue a webbook mechanism. In order to delete all the information with third party, we’re going to build something around it. I suggest we’re going to create an owner role to allow the deleting of the account, and before deleting the account, we’re going to go into a verification mode, extra layer of authentication.
We’re going to do it through email, through MFA just to make sure that the user is actually the user that they claim to be.
Okay. So I know it’s a lot, but I have one last request. So I want to allow SSO self-configuration. SSO is part of the checklist of many, many companies that we try to target. They want to have the ability to log in with SSO.
But I wanted to make it super simple. I want them to be able to configure as SSO by themself. So already when they sign up to our system, they know that they can configure SSO. And also move the SSO from high touch to low touch. Not only self-service, they can test it by themselves, they can configure, they can change it.
Like, something that will be super easy. And also to eliminate the support from our side, not be dependent on us so much.
Cool. And which SSO protocols do you want to support? There are two very famous ones. There is obviously the SAML, which is, like, the top enterprise SSO protocol. And nowadays there’s an OpenID Connect as well. Do you want to support both?
Do you want to support OpenID?
Is there a difference between them?
Yeah. So SAML provides extra flexibility around the extra claims. That can be the group’s information, the IDP information. If you ask me, like, you know, in today’s world, like, being a real enterprise-ready, you got to have SAML built into your product.
So why do we need OpenID?
OpenID is like the new rising star. There are some forms of enterprise. For example, Okta is supporting OpenID Connect by default as well now. So that going, and a lot… Like, some organization prefer to use OpenID Connect for this one.
Okay. So what do you think, like, what we need to do?
I think probably going to implement both. We probably can start with SAML and add OpenID Connect per request, but SAML probably should be the one to go on the get-go. And that brings me to my next question. You know, SAML has two ways of configuration. There’s the static configuration and there’s the automatic magical configuration where they use it basically on the self-serve, just upload the XML file.
I suggest because I’ve seen it in many cases. I suggest that we support this as well.
Yeah. Wow. It sounds super cool. Like, it happens automatically. You don’t need to do anything?
Yeah. I mean, you download the XML file, the metadata XML from the IDP, you just throw it into the product and basically the configuration is being propagated automatically.
And do you think the customer can handle that by themself?
Yeah. Yeah. You know, with a specific guidance, yeah, they can handle it by themself.
And obviously, you know, one of the frictions I’ve seen with SAML configuration is the ability first to test it. Because if a user is misconfiguring SAML for a specific domain, that means that they can easily be locked out of the system.
And that’s a real hustle. So there are two ways to walk around it. The first way, I mean, we going to let them probably test the configuration with them and only them. Like, then we going to let them save after the test. And there’s another way that we can think about is maybe to let the owner of the account have another fallback authentication method which is not the SSO to log into the product so he can recover the account.
This is a must I think, like, the ability to be able to log in also without the SSO. It’s super important.
Cool. And, you know, today’s… Like, when you define an SSO for a specific domain because that domain is being claimed obviously by the SSO, I think that we need to verify that the user that is configuring the domain, especially if we’re providing self-serve mode and free signups, we need to verify that the actual domain is the actual domain of the user.
So we can go easy and say, “If you verified your email and you are probably using the domain, you can use it.” Another way to go is the more secured but less UX side is to verify a domain through TXT records. And then we can do it as well. So that is something…
Your last means, and not a user-friendly area.
Yeah, but it’s for better security and there are a lot of companies that are doing that. And the last one on best practice is the IDP first. So, you know, I was working for NICE and for Check Point, and I hardly knew the URL of any product that I was using.
I was logging into my IDP and I’ve seen all the products that I’m eligible to use. And I was clicking on that and it redirected me to the product itself. And, you know, I speak with a lot of developers in these big enterprises and they all use the same approach.
They don’t know the URL, they’re logging into the products through the IDP. So that’s called the IDP first. And, you know, that’s something that we need to consider to support because it’s a must-have probably for a good SAML and enterprise SSO connection integration.
Yeah. Okay, Aviad, it sounds interesting but super advanced. So let’s talk about it. Think how we can add it.
Cool. So my takeaway from this one, we’re going to implement SAML for start. We’re going to leave OpenID Connect based for another customer to ask for it. We’re going to think about the IDP-initiated login. It’s probably a must, but let’s talk about it. Domain validation is required.
We’re going to take the very UX approach with the email validation. UX-wise, we’re going to add an option to test the SSO and we’re going to let the customer upload their metadata XML so they can have a super easy integration on the get-go.
Okay. So it’s a lot, I know, but I need estimation from you, Aviad, in order to understand. Like, I know for me, like, you’re the best developer. I know you’re a genius, so I know you can do it, like, really, really, really, really fast.
So let me know about…
Come on, Stav. You know, it’s more than I can handle. It’s going to take, like, a team of between two or three developers around three to six months. That’s crazy. I mean, this content is crazy.
This is the most important initiative. Every day that we’re not doing it, we’re losing customers.
I understand, Stav, but, you know, we need to do it right, that security. Let’s do that, okay?
Give me a week. I’m going to search the market. Maybe there are, like, third-party tools that can help us with some of the stuff and then we can focus on, you know, other initiatives as well.
Do you think there is a third party, a service, they’re doing all of that?
Yeah, there are. I’m sure there are.
Wow. Okay. So let’s meet a week from now and let me know if you find something. It can be amazing if we can, like, implement it in two weeks. Wow. It can be great.
Okay. Sounds good.
So just, like, for the next step after we’re doing this, I want you to know that the next thing I want us to talk about is start measuring everything because it’s not enough to turn our product to the best salesperson. We need to start measuring everything the user does and to iterate fast and also to provide some insights to the user during the journey.
So we will talk about the analytics and visibility as part of the data, part of the infrastructure.
Sounds exciting.
Yeah. Thanks, Aviad. It was a great kickoff.
Sounds good. Any questions?
We do have a few questions from attendees. Let’s kick off with a question here. How do you measure the impact of this initiative?
Oh, okay. So first, I have to say the main thing here and the main goal that we have is to turn users, like, to sales-qualified leads. What do I mean by sales-qualified lead?
Sales-qualified lead, it means that they actually understand the value. They have a high intent to purchase a product, and they’re willing to talk about terms and pricing, but they’re already yours. They want the product, they’re looking to buy it. So this is the goal. And for each company, the sales-qualified lead define differently.
So some of them, like, you need to experience a product and invite other users for a couple of days. For some of them, they did a specific thing in the product or invested some time, and then we decide that they’re qualified. But you need to, like, take the users into the journey, decide what is the event that makes them sales-qualified leads, and then this is the plate when the salesperson should do a touch point with the user and convert him to a paying customers or do it themself, like, with a self-service payment.
And then they pay by themself with zero-touch.
Okay. Thank you. We have a few more questions here. This one says, “You mentioned multi-factor authentication. What do you recommend to incorporate there?”
Wow, that’s a great question. Yeah. So there are so many types, so it totally depends on the type of customer. So first of all, I always suggest to incorporate few of them, Google Authenticator or such. TOTPs are by far the most intuitive and protective ones.
But, you know, when you go even to banks… You know, I keep saying that asking my mother to install a Google Authenticator on her phone looks like crazy.
So she’s using SMS, although I explained several times that SMS is hackable really easy. So I normally say do Google Authenticator as a get-go. And then you can do, like, you know, the more advanced stuff, doing fingerprints, doing WebAuthn, but Google Authenticator and such, like TOTPs, is probably a great mixture between UX and security.
It’s really secure.
Okay. Looks like we have another question here. When should I use a hard delete, and when should I use a soft delete?
Yeah, so I think by default we should use soft deletes. That gives us great transaction logs on what is deleted and when and then we can, I don’t know, clean up or put it to a cold warehouse if we’re not required to actually delete, like if it’s not PII.
If there is a PII and we need to comply with GDPR and CCPA and that kind of rules, so eventually we’re going to need to hard delete. So it really depends on the type of the data and the cost of the data. So I would say by default, do soft delete so you can recover at any point unless it’s PII and then you need to hard delete eventually.
All right. Looks like we have one more question about authentication. You mentioned domain authentication. How do you recommend doing that?
So one of the common ways to do domain authentication is through DNS. It’s a TXT record, a CNAME that actually proves that the domain is really yours. So you’ll generate M1 128-bit unique identifier. You ask the customer to add this TXT record to the DNS and then you are basically polling the DNS to make sure that they actually added it.
If they added it, that means that probably the domain is theirs. You just need to keep in mind that once you generate this unique identifier, it needs to be a really unique identifier. Otherwise, I mean, there is a risk of missed domain validation.
Okay. And I think looking at the Q&A tab, we have one last question. This one says, “This sounds like it’s a company-wide effort. What other teams do you think should be involved in the process?”
Yeah, it’s definitely, like, something that gather multiple teams in the organization, but the main partner we have here is the sales because we need to gather to convert as much customers as possible. So I think the best thing is to sit with the sales team and think what is the best time to start a touch point, to contact the…to start talking with the user, to get a touch point with the user during the buyer journey.
Not too soon, not too late. And you need these product developers, like, and the sales to think, what is the best point to do that? The best thing, if we did the job good and we nailed this project, so people will ask to contact the sales and not the sales run after the user.
And this is the best situation because then the chances they will convert to customer is much higher.
The Complete Guide to SaaS Multi-Tenant Architecture
