December 15, 2014
Old School Reading List for New Founders Part 2
In our last post we aimed to establish a shared "history of why" -- leaning heavily on the philosophies behind shared code, team process and...
Thank you very much. It is very, very nice to be here. My name is Samuel Hulick. I run a website called UserOnboard.com, I wrote a book called "The Elements of User Onboarding," and that's led to some consulting work with some pretty cool clients with some pretty cool logos and that has been fantastic.
So, being known as the "User Onboarding Guy," so to speak, that does lead to a lot of user onboarding questions which are also fantastic. I really love to be as helpful as I possibly can. If anybody here has any questions please feel free to email me, I will respond to all of them.
At the same time, there's different levels of questions that I found. Some of them are a bit more surface, some of them are a bit more fundamental, some of the more surface questions are like, "Should we use a tooltip tour or a wizard to introduce people?" Or just recently somebody asked me how long should my intro video be, and those are pretty specific ones that are hard to give generalized recommendations regarding that.
But then there's some more fundamental ones which are, "How do we communicate the core value of our product?" Or, "What are the things that we should be measuring about it?" Or, "What are the first things that we should get people to do?"
Those are things that I can dig a little bit deeper on and provide a general framework around how you can approach that on your own. I wanted to make this talk as hands-on as possible, so that there are exercises that you can go through yourselves instead of just kind of coming away inspired and not doing anything. These are all things that should be really simple to replicate, in that regard.
It started five or six years ago. I was living with my girlfriend at the time and she was going to culinary school, and she was coming home and cooking all these really fantastic dishes, and so every dinner there was this really cool thing that I would get to eat and it was a very nice position for me to be in, but I felt like I should reciprocate. So one day I decided and I told her, in a very official tone, "Sunday nights, I'm cooking. I'm going to create something for you to show you that I care and take a little bit of your burden off of you."
That worked really well for two weeks until I totally ran out of recipes and I was like, "Whoa, what am I going to do now?" So, I thought, I'll go out and I'll get a grill. It's kind of manly, I can kind of experiment, get better at cooking outside, that will be kind of a cool thing. Maybe that will impress her a little bit, something like that.
So fortunately, this is actually the exact model that I got. When you get a Weber grill, it comes with this instruction manual on how you assemble it. Basically going from parts in a box to having a grill that's ready to go, but interestingly, I did not immediately become a very good outdoor cook as soon as I assembled this grill; believe it or not, there were actually some highs and some lows.
One time I literally was talking to my neighbor over here, and the grill was cooking ribs over here, and I'm not joking, a fire ball shot out the bottom of the grill, and he was like, "Do you need to look into that?" I was like, "Yeah, I probably should look into that."
So that wasn't great but, you know, bumps and bruises along the way. Fortunately, Weber also provides a lot of material to help you become better at becoming an outdoor cook. They have a mobile app that you can hold in your hand while you're grilling, or websites where they give you tips, or instructions on how to prepare meat or what temperature they should be cooked to, recipe books all over the place, a YouTube channel where they show you step-by-step how to go through that process; and by taking in all of this material, I actually became a pretty good outdoor cook, or a pretty good griller, which was a satisfying experience.
And I think in some small way led to the girlfriend at the time deciding that she wanted to marry me, and just this past summer, our 4-year-old son got his first grill and he cooked his very first steak ever, and that was just like a month ago, he loves it.
It's something that we get to bond over, and it's a very sweet story.
So in the same way that there is the assembly manual that led to the overall product experience of the grill being able to be used, it is important. At the same time, having a grill that's assembled and becoming rusty because it's unused isn't really getting you any further from a user standpoint of what you wanted to buy the grill for to begin with.
I look at the general life improvement that somebody is trying to get by using the product and why they would bother assembling it to begin with. It's about onboarding as getting people from A to B in their life rather than A to B within the scope of your product.
They have a recurring feature called "Goofus and Gallant" where they're two kids who are faced with the same situation and one kind of screws it up all the time and the other one comes out smelling like a rose. So here we have Goofus, who bosses his friends, but Gallant asks, "What do you want to do next?" So he's kind of showing some servant leadership skills right from the gate, probably knows how to get what he wants, he'll probably go far.
Another kind of weird one that I found when I was doing some research was on the right it says, "Squirrels eat from Gallant's hand," and on the left it says, "Squirrels are scared of Goofus," so nobody wants to really be that guy. It presents an undesirable situation and a more desirable situation, the screw-up and the winner so to speak.
I like to go through this exercise with people regarding their products where basically, without your product in someone's life, what are they really struggling with? What's really frustrating them? How are they coming up short in specific ways.
Then, with your product in their life, if they're using it to the fullest extent that they possibly can? How are they really thriving and succeeding and doing well that way?
Going through an example, say for PagerDuty, a Heavybit company, spending a little bit of time on their homepage I kind of got a feel of what the "without" and the "with" would be, and I can run that down right now.
Without, you're constantly worried about things being broken. You're scrambling to fix long timeouts. Pointing fingers at other team members. Working on a tight budget, or working on a lean product that would be ultimately if you're spending all your time trying to put out problems that could have been put out more easily earlier on, then you're ultimately not spending your time working on building as great of a product as you can.
And if you contrast that with the "with" side of things, you're applying the attention where it belongs. You're showing your boss rad resolution times, only hearing nice things from support, and ultimately and weirdly for a product that's designed to wake you up at night, it actually helps you sleep better at night because you're not lying there wondering if something is broken and if you should be getting up and fixing it. So, providing that peace of mind and that success in somebody's life, that seems to be the general Goofus and Gallant that PagerDuty resolves.
So step one, that was all there is to it, just basically make a list of "without," make a list of "with."
Step two, I say go straight to the source. By that I mean, it's cool to just sit down and come up with a list of things.
It's not so much about what you can brainstorm at the moment, it's a lot more about validating that those are really the issues that people have and understanding how they phrase them themselves. I recommend performing user research in the form of interviews or user surveys.
There are three key moments in somebody's customer relationship life cycle. The first one is at signup because maybe they've been meaning to sign up for PagerDuty, or whatever the product might be for months now, but for some reason today was the day.
Really getting an idea around, "What were the external events that drove them to do that?" What was the emotional motivation that got them to say, "You know what, I'm going to literally type in PagerDuty.com and start signing up." What really triggered that?
Another one that I recommend is at conversion. At conversion is going to depend on how your product is set up. If you charge for it and you have a free trial, it would be as soon as somebody converts out of trial and it's a paid.
If you don't charge for your product, it could be something along the lines of like, the seven friends in three days kind of thing, or just a metric around this person is very unlikely to turn out or be highly engaged, some sort of threshold there. Then lastly cancellation, kind of a bummer, unlike the other two which are better.
Cancellation would be, obviously, if they turn out either explicitly or implicitly by just going too long, or demonstrating signs that they're likely to stop using the product.
I like to match up specific questions with the different segments, and so at signup, I like to ask two big questions which are: What just happened that made you realize that you needed to use our product? Once again, looking at what's that external trigger that really made today the day.
The other question that I really like to ask is: What do you hope to accomplish with it? Because a lot of times, if somebody is signing up for a tax product thinking that it's going to help them save money, or if it's banking or something like that, then onboarding is really not going to help that mismatched expectation to begin with, and it's really a messaging problem.
So getting a really clear idea, "What do you hope to accomplish," but also, "What did you really think you were signing up for?"
At conversion, this is basically somebody has gotten enough value out of it to really stick around and invest in it, so just asking, "What was it that you were accomplishing or what was it that you were doing getting the value out of it that made it worthwhile to continue?"
Also important is the Sean Ellis Test which is basically asking people, "If our product no longer existed, how disappointed would you be?" And getting a really clear idea around whether this is kind of nice to have or something that people really need.
In this case, I'm applying that specifically to features and understanding what was the one thing that you really did or the one key feature that you would be most disappointed to lose.
Then lastly, at cancellation questions would be: "How could our product have been more helpful for you? Obviously it didn't fulfill everything that you were looking for."
Then also going back to the signup question, "What did you think you were signing up for, but didn't get?" Just so we can clearly understand the mismatched expectation there.
Oh, and then to that point, getting a lot of rich insights by asking those questions that you can then return back to the Goofus and Gallant lists and apply things that you know based off of validation and research as opposed to just kind of sitting back and guessing.
So putting a name to this, basically, to the blue triangle, as far as Goofus on the one side, Gallant on the other, what do you call that transition? What is the specific thing that you do to help people along?
So in PagerDuty's case, that's one way I would like to phrase it to help people really clarify what that should be, is to end the sentence with, "Helps people get better at" because that's going to filter out things like, "We help people get better at using our product," or things like that because that's not something people are waking up and really dying to do.
Then also, "Get better at" is something that's kind of action oriented, so it's not just being a race car driver, it would be winning races or something along those lines, and so in PagerDuty's case, I really see it as being better at resolving production incidents. Again I've spent just a little bit of time on their homepage, that's just the general gist that I've gotten there.
Likewise with Stripe, they help people become better at collecting payments online, and it's the kind of thing, where as I called it, "Name your territory," it's also a matter of claiming your territory where if something comes up where somebody is struggling with collecting payments online and they don't think of Stripe, that should be an issue that Stripe takes personally because really that's the thing that they're owning.
Everything along the lines that somebody would be struggling along those should really be thinking, "When I think of struggling with this, I think of Stripe." Well, not the struggle part, but actually, "When I think of the struggle being resolved, I think of Stripe."
Then in Evernote's case, this is a pretty abstract one, but they "Help you become better at remembering things." Or in Yelp's case, I was initially going to say, "Experiencing local restaurants," but then I remembered they had bars and auto shops and things, so I called it "local flavor" very cleverly.
Then in WordPress' case, they "Help you become better at representing yourself online," but interestingly, in WordPress' case, it's also a platform, and so there are a lot of different use cases and a lot of different user types that are there.
I actually used to be a developer and my very first web business was coding custom WordPress themes for clients. So in my case, WordPress was something that really helped me get better at setting clients up with websites frankly, and there were some other options out there.
WordPress was the one that I deemed the best, but that's the one that I went with and really dove in on that, and so from a developer's standpoint, that was really what my perspective was. I wasn't that into WordPress because of its codebase or because of its developer community, those were nice attributes, but really they just made me better at delivering websites to clients, and that was really what was most important to me.
So, step four out of five here is identifying external events.
This is really a question of it's a long leap to get from one to the other as far as making people better at something or helping them become better at something.
It's also kind of abstract and so I want to make it more actionable and in the case of Evernote, for example, the question that I would ask is, "What are the small steps?" The small wins that we can help people with that incrementally inch them towards becoming better at remembering things.
To answer the question what are those small steps, where I look to for opportunities when somebody would be struggling with something and they'd be like, "Aah, Evernote! Suddenly Evernote is very relevant to me." So I use the "This is relevant to my interests" cat as a little signifier there.
But basically, what are the moments where Evernote either is relevant to someone or should be relevant if they don't already know? The two main things that I can think of as far as external events, where suddenly they're relevant in somebody's life, would be when you're trying to save something to remember later or you're trying to remember the thing that you had saved later.
So, going further from that, Yelp would be finding a place and then also when you're reviewing it. These are just moments where you get the urge. "Okay, Yelp can solve this problem for me."
I was actually thinking about this a little bit more and I think that a lot of people who review restaurants, especially on Yelp, have a third motivation which is they want to go back and see how their review went and have their existence validated. I don't really understand where they're coming from, so I didn't want to be too big on that.
And then lastly, at WordPress, going back to my developer experience and setting people up with websites, there were three main things, while thinking about what my workflow used to be in a very primary sense, landing the project was obviously a big deal. I had to make a case for not only my own skills, but also my confidence in WordPress to be able to deliver on the promises that I was making. I also needed to obviously implement the site and then hand it off at the end, and those were the three main phases that I went through that had something to do with WordPress.
WordPress could have been helpful to me in the same way that Weber was helpful to me by providing a spatula or a recipe book or whatever those kind of things might be.
Interestingly, another way to approach this exercise is to take the general gist of it. Of course, WordPress is going to be really closely tied to implementing the website, but then thinking about what things somebody is struggling with right before that happens and then also right after landing the project; that's something that just frankly has to happen before somebody can start working on the project. So what are the opportunities for WordPress to help out there?
One thing that you can do is break these steps down even further and look at all the considerations or activities that somebody has that relate to these overall buckets and how we can be most helpful in that sense.
So in the case of landing a project, you need to identify client needs. That might involve interviewing them or going through a checklist and asking them if they need this or that. So could our fictional start-up perhaps offer checklists or just give people an idea of how to best interview prospective clients and things along those lines?
Researching options, preparing the scope, sealing the deal, which is basically providing the contracts and having that processed and signed, all of those are things that WordPress could, or the hypothetical WordPress competitor, help people out with, but aren't necessarily part of the core CMS code base.
At the same time, going back to the grill versus becoming a better cook, your business offering is helping people become better in a particular way. Whether that happens within your product or outside your product isn't really as relevant because both of those are really what your business is designed to do.
In the same way going through implementing the site, gaining access, this was something I was thinking about as being a big part of the stumbling block that I would encounter when I was working on these client projects; but it was also something like, "Well how could a CMS possibly help you with that?"
But then I remembered all the times I was beating my head against the wall just trying to explain the difference between what web hosting is versus what domains are and even if this hypothetical company provided a one sheet that I could email to people, and say, "This is what hosting is, these are what domains are, it's kind of like a phone number for your website," or whatever that might be, then once again you get, "Oh, thank you for taking this off my plate hypothetical company."
You're building more and more psychological lock-in and loyalty as you're being more and more helpful and building that trust which really is once again the unfair advantage as compared to other companies that just exist solely as a product and have to stand on their own merits that way.
Then also setting up the admin, which WordPress is great at. They have the famous five minute install and then also coding/installing the theme, learning the code base. They have great, great documentation. That would be something where I wouldn't see a huge amount of opportunity outside of what they're already doing.
Then QA-ing, where you're part of the wrap up of the implementation phase. You're going in and making sure all the code is working properly, cross-browser testing, things like that. I know that there's a third party plug-in called WP Theme check, but it's not part of the native product, something like that where you're building it in you can certainly go through all the developer tools and make sure everything is singing as it should before heading off to the client would make a lot of sense.
Lastly, handing it off itself.
You're delivering access to the client so a button that you can click or just enter an email and send it to somebody, and then they suddenly have all the information laid out in front of them instead of having to draw from all these different sources and put it into an email and send it to them.
Once again, maybe it's taking five minutes or ten minutes off of somebody's plate, but they will love you for it. Billing the client, asking for referrals, and finding more projects was the last one where I thought, "How could a CMS possibly help you with finding more projects?"
Even just a little bit of thinking on it, I thought, "Well they could offer a job board or something like that where all of a sudden, if people are finding me through the WordPress competitor hypothetical job board, how much more likely would I be wanting to, as a developer focus solely on that CMS?"
Interestingly, Slack actually kind of does this already. They have a job board where they say, "If you are a Slack customer, you can post jobs here for free and we're going to help match you up with people."
So it's not a core part of their product, it doesn't live anywhere in their software, but it helps solve the overall problem that they exist to solve. On that note thank you very, very much for letting me give the run-down.
Once again, the five steps that I really recommend are: (1) Contrasting the with and the without. (2) Going straight to the source to validate what your guesses there are. (3) Naming your territory and claiming your territory. (4) Identifying the external events- what are the things where suddenly your product is or should be really relevant in people's lives? And then (5) Covering your bases- Making sure that all the areas that are inside those external events are covered as best as possible and take it from there.
Thank you very much.
So what do you measure and how do you measure it?
That's one nice thing about the framework overall as well, that if you're looking at running a company, let me see if I can pull up a really good example, if you're Yelp, for example, and you're wondering what are the things that we should be measuring?
From an onboarding standpoint, you might be looking at the steps in your set up process, so, how many people are we getting to the site and how many of those people become email signups and how many people go from email to confirming their address and then finding their first restaurant or something like that.
But a lot of times when people talk about measuring onboarding experiences, they measure the blockers that are put in the way. We put all these obstacles in place of somebody actually doing what they came to do and you're measuring how people go and how many people make it from one to the other to the other, which is interesting and relevant.
But at the same time, when you're measuring by those kind of things, it almost implies that those steps are making progress in somebody's life. So looking at confirming your email address, that really doesn't help anybody get better at the thing that they were looking to get better at when they signed up for your product.
If you're looking at, "This is the step where you confirm your email address," I would not mistake that for progress necessarily. So the things that I would really be looking at in Yelp's case, would be finding a place and reviewing it.
We talk about from a gross standpoint the one metric that matters, or the core user engagement, things like that. I would really look to derive those specifically from that first, what are the moments of relevance standpoint? Then go from there.
And then as far as how to measure certain products like Mixpanel, KISSmetrics, Google Analytics, I believe KISSmetrics actually just came out with a new user acquisition tool today, so there's that as well.
One thing that I really like to do is go through the user table and go through usage logs and just see, then I'll contrast everyone who signs up.
What's the average person or average user do versus the people who have become really highly engaged and become really the best users? What were their first steps, or what were their first two weeks in the product like? What kind of actions did they take that maybe the average user doesn't take and how can you kind of use that to inform your design and get more people to take those specific actions?
I would like to answer that, but I would also like to give a caveat that reviewing the onboarding experiences as a user or as an outside observer is more different than working with the teams themselves for two major reasons.
One, I don't know what those conversion rates or engagement metrics look like, and two, I don't know what kind of internal constraints those teams are faced with, so I try to be very humble and identify my own subjectivity there instead of coming out and saying that this thing is wrong or not.
I've had too many experiences where I've spoken with teams and said, "Yeah, so this part kind of sucks, right?" and they're like, "We hate it, but it works really well," so I really try to maintain a sense of objectivity as best as possible in that sense.
That said, philosophically there are certain onboarding design patterns that I don't really agree with. Looking at tooltip tours, especially an overuse of coach marks, and adding multiple ones at the beginning, basically saying, "Hey, welcome to our page." Then it's just pointing to five different buttons and hoping people will know what to remember when the time comes when that button is going to become relevant.
Or even when it's not done all at once, but linearly where there's a tour and you're thinking, "This button does the thing that it's named, and then this button does the thing that it's named," is not recommended either.
I really like to get people to do, you know, how can you get people in and engaged in taking actions in a meaningful way as quickly as possible?
Then the last kind of knit pick I have with tooltips is a lot of times there is probably a pretty profound and well known UX issue that they are papering over and so a lot of times you're looking at, "Okay, well, let's just throw tooltips," basically in the way of what I think of when you invite somebody over and you try to clean up at the last minute and then you let them in you're like, "It's such a mess, sorry guys." That's what tooltips kind of shout out to me.
Then another big one, and this one I have more data on, is email confirmation, as I mentioned earlier. When looking at the drop-off rates there or just the loss of momentum, a big, big thing that I look at is that somebody is finally there, today is their day to sign up for your product, and they get a certain amount in and then you literally say, "Go away." Go to, of all places, your inbox, and I hope you come back unscathed.
I really like to delay email confirmation as much as possible, if not removing it entirely.
Those are two ones that I would recommend looking into.
From a survey standpoint there are different ways you can do it.
You could have the obnoxious motto that obscures the rest of the screen, basically saying, "Hey, what do you think of our website?!" before you've even seen the website. Those I don't typically recommend.
Or you can have something that's a little bit more unobtrusive, but still in the moment. Take Qualaroo, for example, it's there if they want to answer it. It's not if they don't, or well it's there either way, but they can continue doing what they want to do, it's not preventing anything from moving forward.
Then, as you mentioned, after the fact surveys, Intercom would be great for either in that type of messaging. They also have a really great email functionality where you can be sending out things like, as soon as a user has done X, Y, and Z, it shoots out an email asking them something. That's something that I would look into.
There's also an application called customer.io, that's a little bit more focused on life cycle email management, but could also easily be used for surveys there.
Then the only other thing that I would recommend in a non-survey form is Live Chat and I'm a really big proponent of maintaining a presence in your onboarding experience from a live chat perspective because it can kind of be like the canary in the coal mine where you're looking at, a lot of times onboarding is not something that you're going to be experiencing, even if you're using your own product on a daily basis you're not signing up for it on a daily basis and there can be a lot of things where you push one update out, two weeks later you push out another one, three weeks later you redo the CSS and nobody really noticed that it totally hosed your onboarding.
So from that standpoint not only are you getting that really warm emotional feeling of helping people out in the moment and getting those user insights, but you're also there to kind of save the day if people are just like, you're telling me to click a button that doesn't exist or something like that.
I think a lot of times about, and even WordPress which you know, you could use if for so many different things, those gigantic kind of products like Minecraft level where you could be playing totally different kinds of like survival versus building a city versus creating a computer inside Minecraft or super collaborative versions, it's all one big sandbox that can be used in a lot of different ways.
The same way with WordPress, for example. At the end of the day, there is a kind of general essence of it. That those people are going to be coming- there's a core engagement factor. One way I like to do it is not to be so vague that it doesn't speak to anybody, but speaking just basically to the fundamental problem that you solved and then quickly getting an idea of what are the different reasons that people would be coming to your product and what are the different ways we can help them.
The thought exercise that I really like to go to, similar of the Goofus and Gallant example, is, "What is the crappy situation that someone is in that we can help them out of?"
So you're not looking at your user types as saying, "We develop products for project managers or construction workers, pilots, or whatever that might be, but developers of course. Looking at it, we help people who are faced with this problem, not being faced with that problem anymore or even beyond that, becoming really good at the thing that they're struggling with.
So looking at the situation that they're in and speaking directly to that situation in my mind works a lot better than, "We help people who are doctors, lawyers, Indian chiefs," whatever that might be, so that's one recommendation there.
As far as directly addressing those people, that's something that when you are getting a significant amount of traffic and you have a bunch of different landing pages, you can do a lot of customization based off of just metadata that you know about them.
So if you know what the search was that they conducted that brought your site up, or if they came in through a landing page that was specifically designed for that one situation, you can craft your onboarding experience around that as well.
That is a good question. A lot of times, there's a thing called Conway's law where the general rule is that the way that a team is organized will be reflected in the way that the product that the team created is organized.
So, if your API team doesn't speak to your other team, there probably won't be a lot of cross-communication within the product that way and a lot of times in traditional organizational organization there is a marketing department and a product department; in between is really where you find user onboarding from a customer experience standpoint and also where you find a kind of "no man's land" in that regard.
So marketing is often times focused on PR, awareness, traffic, and kind of concludes with signups. Typicallyyou'll see that's kind of where marketing says, "Hey, this is the output that we created, this many signups, product can take it from there."
Then product is really incentivized to be creating new features, increasing the performance of the site, things of that manner, and they're really focused on highly engaged users, a lot of times especially if your product involves a dashboard, you can really tell when the product team was just designing for the dashboard to have stuff in it for example.
Then you don't see the, "Our dashboard doesn't have stuff in it version", and looking from an organizational standpiont which of those two departments is going to really lead the charge from a user onboarding perspective can a lot of times come down to and from a departmental sense or from a role perspective, who is even going to be incentivized to care about that, and so that's one thing that I really look at.
A lot of times people who have user onboarding in their job title, like on their business card, are weirdly, a lot of them are from a customer support background where they're very sensitive to what the customer needs are and have probably heard a lot of people complaining about the user onboarding, especially when you think about the amount of tickets that are created in someone's first week or in the first 30 days versus ongoing after that; looking at onboarding as being that kind of problem.
A lot of times I see customer support people kind of graduate to a user onboarding role, but really anywhere across the organization, where you're really looking at what your conversion rates are and taking all of those signups that marketing worked so hard to get and are collecting, these are people to take part and then engage in the features that the product worked so hard to build and looking to bridge that gap there.
So my general take on that is, cooking outside versus assembling a grill. Basically that onboarding a lot of times is how can we set people up with an account and that's a very easy thing to look at. You can say, "Well they have to create a project and then add a friend and then invite a neighbor," or whatever those activities are.
A lot of times those don't necessarily map directly to making progress in someone's life for one thing, and a lot of times people are struggling with the core problem that you're helping alleviate through your onboarding way before they ever get to your product and also way beyond what your product can do.
So if somebody is becoming super great at, take the WordPress example, delivering websites to clients, then that's something that they've probably been trying to do by hand for a long time. You can also look at it like when you think of onboarding, it's like people switching to your product.
People immediately assume that they're going to be then switching from your direct competitor to your product, which isn't necessarily the case. Probably more often than not they're switching from using a spreadsheet or Gmail or pen and paper or screwing it up in their head and really struggling from that capacity, doing it by hand as opposed to well, I'm going to go from MailChimp to Campaign Monitor.So if you're looking to build in that advantage, unfair advantage, from a user onboarding standpoint, it's really kind of sowing those seeds early and often.
So looking at what are all the things that people are faced with, for example, how helpful would it be to give a checklist that helps you identify what your client needs are, that's a very basic thing, that's a couple hours of work and then maybe a little bit of graphic design resources, but those are the kind of things where you're winning those small wins early and earning their hearts and loyalty as you go.
The onboarding stakes have been significantly lowered because they've already decided to go with you, but once again, it's kind of zooming out from the little purple triangle of assembling a grill to the big blue triangle of becoming better at cooking outside. How can you cover all of those bases as thoroughly as possible?
When you're talking about abstract things like, "We make people better at delivering websites to their client," you could easily say, "We help people live, live well or be healthy or make money," or whatever those things are and so you don't want to go so abstract that you're competing with literally every company in the world.
It's really identifying a specific thing that people are struggling with and helping alleviate that as comprehensively as possible.
Even as far as just qualifying, for example, looking at these bullet list items here, even here, you probably don't want to be helping people with all of these things. This is a lot more of an exploratory exercise and just going through this with people it can often the case of, "Oh yeah, well we're just doing nothing, we have this very thin slice right in the middle that we're helping people with, if we're helping them with that at all."
Or if it's code that's sitting on a server, hopefully they can figure out what the meaning of it is. So really, looking at it across the board comprehensively, even if we just come up with a couple of things that we're going to help people with right now; that we think are A- Going to be relevant and really closely tied to making progress in that particular way and B- Affecting the most people, those are the two things that I would really look at.
Pick one, have some metrics around what it should actually be accomplishing and if it doesn't do it, maybe move onto another. Something along those lines, but looking at what the overall job is that people are hiring your product for and how you can help them outside of your product as well as inside it.
Thank you very much.