Creating Successful SaaS Products by Ramen.20160215

Creating Successful SaaS Products: An
Introduction to Product Success

What is Product Success?...................................................................................................... 3
Who Should Read This Book? ............................................................................................... 8
The ...................................................................................................................................... 9
Part 1: Low Hanging Fruit ................................................................................................... 10
◦ Error Pages............................................................................................................... 11
◦ Email Receipts.......................................................................................................... 19
◦ About Pages ............................................................................................................. 27

Part 2: Getting Into A Cadence ........................................................................................... 38
◦ Status Pages............................................................................................................. 39
◦ Long Running Questions (LRQs) ............................................................................ 56
◦ Changelogs............................................................................................................... 50
Part 3: Architect for Success ............................................................................................... 67
◦ Mobile-first Design .................................................................................................. 68
◦ In-app Communication........................................................................................... 76
Conclusion ............................................................................................................................ 80
Thank You ............................................................................................................................. 81
Shameless Plugs for our Products..................................................................................... 82
Credits ................................................................................................................................... 83
Appendix: The Original Product Success Blog Intro Post................................................ 84
2 Product Success: Creating Successful SaaS Products

What is Product Success?

The best way to start this story is to talk about who the people are behind this book:
Ramen. Ramen is a company that was started in 2014 by a bunch of people who
have been building products for a very long time, mostly on the web. The driving
vision that brought us together was a frustration over the waste we saw time and
again by brilliant people working to solve worthwhile problems.
Things like Lean and Agile have come along to help combat waste when it comes to
building really anything. But when it comes to eliminating it, the methods are far
from a silver bullet for SaaS. There is still a lot to study and learn. Where some
products seem to invite success at every turn, the vast majority struggle to just
barely keep their heads above water.
We began to think: “Is there something systemically different about those products
that succeed that could be distilled out and applied to those that struggle?"
Over the past decade, all the people at Ramen have worked on a huge number of
SaaS products in various capacities. But it’s been these last two years in particular
that we’ve begun to really focus on that question of why some products seem to
“have it easier." We started to pay attention to SaaS products in any vertical, and
despite being in different industries, we began to notice some similarities among the
successful products. What first started as loose anecdotes quickly turned into
repeating patterns. We saw again and again that products, no matter how different,
could do similar things to increase their overall quality regardless of how different
the products themselves might be.
Strategic Product Success

Upon further inspection, what was happening started to become obvious, and it all
has to do with what we call the Product Periphery. The Product Periphery isn’t what
happens inside your product. It’s not the core. It’s not the “Minimum Viable Product
(MVP)" to use a popular term. But it’s… sort of… related to the product. These
similarities that we started to see didn’t fall into other traditional categories either.
Product Success: Creating Successful SaaS Products 3

They weren’t a function of Customer Support or Product Design or Customer Success
or Account Management. But they all had a common thread: they would somehow--
sometimes directly, but most times indirectly--contribute to creating and fostering an
environment where product teams and customers communicated with each other at
a higher level.
Product Success is about what happens at the product periphery, and being
thoughtful about every single interaction with customers in the hopes that it will
increase a customer’s trust in the product and their knowledge about the product
team’s intentions. In turn, this has the effect of raising the level of discourse between
customer and team. These higher quality feedback loops result--very directly--in
better products.
If you don’t want to read the whole book, then here’s a TL;DR for you: First, share the
book with a friend if you haven’t already and then think about this question when
working on a product:
What are the “boilerplate" things that you just do because you’re supposed
to?
The thing about this boilerplate is that they are common across all SaaS products. So
even if you have no competition in your space, your customers will judge you on the
quality of these interactions. Email receipts, About Pages, Availability of real-time in-
app customer support, Changelogs, and Status Pages are just some of the things we
talk about in this book. We’ve seen time and again that a commitment to doing these
things properly drastically raises the bar.
The SaaS Product Hierarchy of Needs

There’s an analogy to Maslow’s Hierarchy of Needs that we’ve found applies very
nicely to Product Success. There are 5 levels to the SaaS Product Hierarchy of Needs:
Function, Reliability, Communication, Community, and Product Nirvana.

Those first two levels are what is required for a Minimum Viable Product. This is
the point where people will start paying for your stuff:
Function: Does the product do something valuable? Yes? Great. Done.
Reliability: Do the servers stay up all the time? Will the startup building the product
still be around 6 months? Will it be able to handle the pressure of our high traffic
usage? Yes? Whoohoo! Super. Next.
Next up is setting the stage for Product Success. Are you fostering an environment
where users where users are giving you honest, thorough feedback on their
experiences? This is the point where products start to turn the corner:
Communication: Does the product communicate when it’s going down and why? Is
it easy to send in support requests, and do I get timely responses that instill a sense
of trust?
Community: Do I feel like there are people on the other end of this app that actually
give a crap? Do I know any of their names?
And lastly is the pinnacle: Product Nirvana.
Product Nirvana: This is a state that we purposefully leave undefined in recognition

of the fact that Product Success is by no means the end of the journey, and that
there is always more work to be done.

What’s great about this analogy is that whether you come at this from the
perspective of the Product Creator or the Product User, the analogy still fits. Both
sides crave these levels being fulfilled. Product Users crave it because it makes them
want to continue using the product. Product Creators crave it because it creates an
environment where they get incredibly detailed, and high-value feedback regularly
from customers.
Product Success is a new category

Product Success is a new category. Nobody has ever used the term this way before,
and as far as we can tell nobody has ever written about this topic under a different
name. This has a few repercussions:
First, the wording and the thoughts here are new. We’re not exactly seasoned
authors over here at Ramen. At times, the writing might be a little long-winded or too
technical or even contradictory. We’ve tried our best to mitigate this, but we’re not
perfect. To that end, you’re going to see these little icons all over the book. These
are links, and you can click them. They link to a feedback page on our website where
you can leave comments about that part of the book. We’ve never seen anyone else
do this, but we think it will help us learn from you how we can improve this and
future books.
Second, we haven’t been able to conduct extensive case studies to empirically

“prove" what we’re saying. We don’t have data that says “If you do best practice X, we
have measured ROI Y across Z samples." What we do have is lots of anecdote backed
up a lot of experience. The pages of this book have been reviewed by scores of
brilliant product folks from dozens of companies. However, if you see a little and
want to give us some data, we’ll be sure to include it in future editions :)
Third, we are huge hypocrites. If you go through this eBook and then you look at all
the things we build, you will almost certainly find instances where we don’t follow
our own best practices. All I can say in response is that running a product is a lot of
work, and there are a LOT of things that any company could be doing at any one
point. You have to prioritize, and that means that at least few balls are always going
to be dropped.

This book is not meant to be a clarion call for everyone to stop what they’re doing
and implement these best practices in their next sprint. It is simply meant to give you
something to think about as you struggle with something that all Product Creators
struggle deeply with: getting a better understanding of what customers need and
want in the pursuit of creating successful products.
Read on, and let us know what you think. We’re looking forward to hearing from you!
What did you think of this introduction?

Who should read this book
There aren’t many requirements to read this book. You don’t need to be technical.
You don’t need to be The Boss™, although if you’re not the boss you should
probably send the boss a copy of this when you get a minute.
The only real “requirement" is that you’re working on building a SaaS product.
That doesn’t mean you have to be at a SaaS company. You could be at a very large
company where a SaaS product is just a small part of the overall product line or you
could be working on an internal tool that’s only going to be used by a hundred
coworkers. Regardless, these best practices can still help you create a successful
product more efficiently.
Beyond working on a SaaS product, there are really no limitations on who can
benefit from this book. At times, we will specifically address Product Creators:
people who have a significant role in the decision-making process when it comes to
figuring out what goes into a product. However, since responsibilities often blur in
organizations, the more people exposed to these ideas, the better. People in
marketing, engineering, sales, product, or operations can all benefit from this eBook.

The
The
One thing we love at Ramen is immediate, real-time, contextual feedback. The eBook
format doesn’t really afford us the opportunity to get feedback in that way, and that
drives us nuts.
We started to think about ways we could easily get feedback on this book in order to
improve future editions and future eBooks, and we came up with this: .
Throughout the book, you’re going to see this little icon: . You can click it, and
when you do it’ll take you to a page where you can give feedback on the section of
the eBook you’re reading.
We’ll take praise or constructive criticism. It’s all good :)

Part 1: Low Hanging Fruit
In this unit, we’ll discuss some relatively simple things you can do to get started with
Product Success today. These are things like overhauling your email receipts,
updating your About page, and modifying your error pages to be better sources of
information.

Better Ways to Use 404 & 500 Error Pages
Better Ways to Use 404 & 500 Error

Pages
When something goes wrong with a web app, it’s common to display an error page.
There are dozens of different types of errors, but the most common are 404: Not
Found and 500: Server Error.
Your end users get a 404 when they go to a non-existent URL, such as
https://ramen.is/a-url-which-will-never-exist-or-will-it. This can happen due to typos
or things being deleted/moved. They get a 500 when there has been some sort of
error in your application.
In addition to 500, there are dozens of other error codes such as 400,
401, 402, 403, 502, 503, and 504. Each of them means something very
specific, but many web apps lump them together under a single, static
error page. For the sake of brevity, we’ll refer to all errors as 500s for
the rest of this article.

Since error pages mean–-surprise!-–there’s been an error, they are usually very
simple, static pages. You wouldn’t want to put any dynamic code in your error page
that could throw an error, which would then want to load the error page, which has
code, which throws an error :) Because of this, we’re all familiar with the standard
error pages from the likes of nginx:
nginx: Who’s a bad gateway?! You’re a bad gateway!
Ruby on Rails rocked the error page world when it launched this radically advanced
error page back in 2006:

Rails: Much style. Many color.
We should spend way more time on our error

pages… making them funny!
The next big evolution in error pages came when people realized they could make
them funny. We have Chris Coyer at CSS-Tricks doing stuff like this:
Title tag: “You’ve ripped a hole in the fabric of the internet. Love, Chris from CSS-Tricks"
Even companies like The North Face got into the game:

Goats: Don’t let them win.
Is this an error or a 404 page? Not super clear. Report to the Web Administrator
doesn’t really scream “We care about your experience and want to fix whatever it is
that got you here." This sentiment is reinforced when you click it and find that it’s just
a mailto link. This is a great example about how putting the wrong kind of effort into
a 404 page can actually be a net negative.
Error pages should clearly state that something is missing or broken (Tweet this). To do
otherwise, even for the noble goal of Goat Shenanigan Awareness, risks confusing
your customers.
SaaS != Everything else

For many types of businesses–-i.e. content or e-Commerce sites–-what we saw above
isn’t ideal, but it’s not a huge tragedy either. Visitors pretty much expect to get these
error pages. Who hasn’t clicked on a link in a tweet or email that had a typo? It
happens all the time.
But for SaaS products, these pages are a big deal. Your customers might have been
mid-workflow. This might have been the one time a month they click on that button
to get whatever it is they pay you $5,000/month for. They click “Send" and get an

error page. Not cool. If you’ve spent any time making a funny 500 page, at that
moment your customer might not share your sense of humor.
Error pages should be better

I’d like to think that by this point you’re already onboard with how important it is to
ensure your error pages don’t just say “LOL ERROR", but I’m going to belabor the
point.
Not only does an error page mean your customer was unsuccessful at finding or
doing something, but sometimes you don’t even know it’s happening.
Product Fail Yeti says:

If you’re not using an exception monitoring service like Rollbar or Airbrake, AWESOME. Don’t ever use
them. Who cares that these services have extremely generous free tiers, and are dirt cheap after that?
Be just like me. Let your users hit those errors without having any idea about it!
Can you believe that guy? Don't listen to the Yeti. #FightTheYeti
Even if you have exception monitoring in place, most of them don’t record 404s. I
once learned this the hard way, because it turns out that it’s a super big deal when
your billing page is at /manage/billing but your navigation links to /billing.
#facepalm
All that being said, it’s still possible that you will miss errors. There are multiple layers
of software between the Internet and your web application (eg. nginx, varnish,
unicorn), and it’s possible for any layer to throw various types of errors even when
there hasn’t been an “error" as far as your application is concerned.
How error pages can be better

Error pages are usually static for good, technical reasons, but that doesn’t mean
there isn’t room for improvement.
Your error pages should ask your customers how they got there and what they were
expecting. Your error pages should apologize for the inconvenience. If it’s the truth,

your error pages should tell your customers that you’ve been notified, give a crap,
are looking into it, and will follow-up with them.
Early on in Ramen’s history, anytime someone hit an exception, I would

personally email them saying that I saw the error and a fix was coming.
For every exception. This was never an overwhelming amount, and I
believe it was one of the keys to getting our business off the ground.
Error Page Toolbox

Asking questions on your error pages is something you can design and build
yourself. Our best practice is to ask: “How did you get to this page?" and supply a
series of options:
1. Clicked a link or button while using the app

2. Clicked a bookmark — Great for identifying changed routes in your product
3. Followed a link shared by someone — Can quickly give you a hint as to
whether this is actually your fault
4. Other — Always give them an out
In addition to asking questions, a custom solution also gives you the flexibility to
store additional details like exception data and session information to aid in
debugging.
One thing to keep in mind, though, is that to work correctly, this system must be
isolated from your main application in the event of a cataclysmic failure. That means
using a different application, database, and should probably even be hosted on a
separate server. That’s a lot of work, and I told you earlier this was Low to Medium
on the Initial Effort scale, so below, I list three 3rd-party services you can use on your
error pages. Each of them have generous free usage tiers, and can be setup in ~5
minutes.

Method 1: Google Forms
Google Forms is free forever, and provides a simple way to add a questionnaire form
directly to your 500 pages. I was able to create a new form and add it to Ramen’s
error page in about 4 minutes and 30 seconds. Not kidding. Here’s the video sped up
4x.
Method 2: Wufoo
Another option is Wufoo, which has a generous free tier and integrates with many
other services. It took me under 5 minutes and 30 seconds to create an account and
have a form live on Ramen’s error page. Here’s that video sped up 4x.
Method 3: Ramen
Not all chapters in this book will promote Ramen, but for this best practice, Ramen is
an option. We have pre-canned 400 & 500 questions that you can use, and some
extra goodies that help managing responses at scale a breeze. Video here.
What about single page apps?

We haven’t mentioned Single Page Apps (SPA), but they deserve some attention
here. SPAs are apps written with lots of front-end JavaScript. If you’re not technical,
but you’ve heard your tech dudes and dudettes refer to Ember, React, Meteor,
AngularJS, etc…. then your product is probably an SPA. Once the first page loads in
an SPA, the page doesn’t refresh. The URL might not change at all as you move
around the app. If the URL does change, related changes to the state of the
application are almost instant.
SPAs are built differently than ‘standard’ web apps, but everything we talked about
above still applies. However, since most SPA errors are asynchronous, there’s not
really any error page to show.
Normally, SPAs are built to catch errors on their asynchronous requests and display
error messages accordingly, but errors still slip through the cracks. And if anything,
it’s those errors that will be most confusing & frustrating for your customers. In this
case, it’s still possible to use the above products to ask your customers questions

when they encounter errors. You just need to do a little extra coding. In the case of
jQuery w/ Ramen, for example, all it takes is the following snippet to pop-up a
question on an AJAX error:
// Ask Ramen 500 question on AJAX error

$(document).ajaxComplete(function(e, xhr, opts) {
// You may want to also catch 401, 403, 406, 422, etc....
// Talk with your developers to figure out which status codes
// need to be monitored.
if (xhr.status > 499 && xhr.status < 510) {
if (Ramen) {
Ramen.event("560ad1f87765626520281000");
}
}
});
In the wild
We looked around for companies that do this well to include as case studies, but we
had a tough time finding any. We believe this is for 3 reasons:
1. Fewer people use SaaS products than visit content/e-commerce sites, so

they’re less likely to pop up in “Best Error Page Posts" that abound if you go
Googlin’ for them.
2. Exceptions in SaaS products are much rarer per pageview than for content/e-
commerce, which further decreases the chances of them being shared &
found.
3. And, sadly, because so few people are doing it.
If you have built or used a SaaS product that has great error pages, please let us
know: .

All SaaS Products Should Send E-mail Receipts
All SaaS Products Should Send E-mail

Receipts
Researching this topic, I know that a lot of people tend to agree with this, but the lack
of receipts in my inbox tells me there are a lot more people out there that don’t
share this opinion. People that fall into the latter category might think things like “I
thought this blog was about Product Success. They already paid, ergo product
succeeded. The subsequent emails are the purview of marketing & customer
support! Why does this matter?"
I understand that point of view. Running a product is an exercise in herding cats, and
it takes a while to get to everything you want to do. However, as I’ve said a few times
before, Product Success is about what happens at the periphery of your product, as
it’s in those moments that customers face crossroads: do they come to trust you
more, or do they get annoyed and think about sending out a mean tweet.
E-mail receipts are virtually no effort and have huge upside for SaaS products.
(Tweet this)

Your job is to make people’s lives easier, not harder.
Have you ever signed up for a trial, logged into the app once, and found out 3
months later you had been paying $57/month for it? This happened to me just last
week. The company in question was very understanding about it, and refunded my
money without putting up a fuss.
From a customer service point of view, they did great, but let’s look at it from a
Product Success point of view by breaking down the end user experience:
1. We use this service at Ramen. I saw a charge on our monthly transaction

report for $49.
2. I was checking out my personal finances later that week when I noticed a
charge from the same company for $57.
3. I thought it was a typo, or that I needed to change cards, so I dug our monthly
expense reports back up to see if I was mistaken. I wasn’t. There were two
charges.
4. I logged into my account and messaged them about the double billing.
5. I sent screenshots of both bills.
6. A few minutes later, I went searching through my email for any emails from
this company in July, when these secondary charges started happening.
7. I found an email welcoming me to a new trial account.
8. At that point, I remembered that I had signed up for a new account to show
this product someone, and realized I must have been required to put in a
credit card at that time.
9. I go back into the product, cancel my previous request, log into the fake
account in an incognito tab, send a new request asking for a refund.
10. They are very helpful and give me a refund with a smile.
But that took like 10 minutes of my life. Despite customer support doing a great job,
they did not make my life easier. They made it harder.
Sending an e-mail receipt would have prevented this problem from ever existing. I
would have gotten an email a couple months back, replied to it saying “whoops can I
get a refund?", and gone about my merry way.

You want people to constantly evaluate the value of

your product (Tweet this)
This is a tough one to swallow, but the truth is that you want your customers
thinking “do I really need to pay for that?" every single month. It’s the only way to
ensure your product continues to deliver true value, and increase the chances that
your business will be successful.
To use a biological analogy, e-mail receipts are like germs: they strengthen your
“immune system" by making you deal with people churning who aren’t getting a ton
of value out of your product. E-mail receipts make you stronger.

Why send e-mail receipts when you can NOT SEND E-MAIL RECEIPTS?! People will forget they’re paying
you, and your numbers will look great!
You don’t want people to question your motives

(Tweet this)
Product Fail Yeti raises an interesting point. When you get into the thousands of
paying customers, and have raised tens of millions of dollars, those board meetings
can get pretty intense. Is not sending e-mail receipts an oversight? Or is there
concern that starting to send receipts after not sending them may result in a jump in
churn due to customers canceling once they realize they’re paying for something
they’re not using?
I tend to be borderline-delusional in my optimism on most things, and that definitely

carries over into how I judge entrepreneurs. Do I think companies that don’t send
our monthly receipts have nefarious motives? Absolutely not. Running a business is
really hard. It’s even harder than most people who say it’s hard realize. Lots of things
get forgotten, especially when you’re faced with explosive growth, but that’s when
focusing on Product Success matters the most.

What goes into an e-mail receipt
Pretty straightforward, but let’s break it down anyway.
1) Say who it is coming from
Not joking. We’ve seen email receipts before that didn’t actually say who they came
from.
2) Say what account it is for
People often have multiple accounts on a single service. Make sure to include some
kind of account # or other unique identifier.
3) Include the original amount, any discounts, and the final amount
If you went through the trouble of giving someone a discount, remind them of it!
4) Have the reply-to go somewhere
You should never send emails with a no-reply@ email address, and especially not
when it comes to receipts.
5) Say what card was used
Include the type (Visa/Amex/MC) and last 4 digits on the card. If you have the name
on the card, send that along too, as it can help avoid some headaches.
6) Explain credits
If there is a credit on the account that is being charged against, make that clear. If
there is a clear date where those credits will be out, say it in the receipt. For example:
“Your credits will last 3 more months. After that, we’ll start charging your card on file:
Visa 5344"
7) Verbosely describe overages
When it comes to charging overages, no amount of detail is too much. If you need
the email to link out to a web page to show all the details, that’s fine, but make it

clear that there were overages and let your customers know you’re able to describe
them.
Renewals and Annual Billing
When it come to renewing, e.g. in the case of Annual Billing, you should give your
customers ample notice. This is a great opportunity to learn from a customer. Don’t
fear that they might churn when confronted with the fact they’re about to get
charged again. As I said above, it’ll only make you stronger.
Tools
This week is pretty simple. When you charge someone, send an email. It’s basically
free. It can be an ugly text email or a beautifully-designed, responsive HTML email
like this Mailgun design:

Or, if you use Stripe, you can check this box to have them send emails for you:

In the Wild
Keen.io
I mentioned Stripe above, and Keen uses it. Here is an example receipt from Keen
automatically sent through Stripe:
Slack
Slack does annual billing, and they send you emails when credits are added to your
account:

Beyond
If you aren’t sending email receipts, start doing it. They can be really simple to start.
Once you get going, or if you already are, we’ve found a bunch of great articles on
what you can do to make your email receipts work for you:
• http://www.getvero.com/resources/dollar-shave-club/
• https://litmus.com/blog/best-practices-for-optimizing-order-confirmation-
emails
Have you come across any companies that have phenomenal email receipts? We’d
love to hear about them for a future edition of this book:

Why SaaS About Pages Should Matter to Product Creators
Why SaaS About Pages Should Matter

to Product Creators
They go by different names–Team, About Us, Our Story, Company–but regardless of
the title, tone, or details, About Pages convey something pretty powerful: who the
humans are behind a product.
Many people have different reasons to care about a great About Page for their
company:
• HR wants to use it for hiring

• CEOs want to use it for fundraising
• Marketing wants to show off the company’s creativity
• Individual contributors enjoy seeing their name & title
But Product Creators have reasons to care about the About Page too.
In today’s article, we’re going to talk about why you should care about the About
Page, refute common justifications for not having one, explore some best practices
that even companies with existing About Pages can use to improve them, and
expand on how larger companies with many products can use About Pages at scale.

We made an infographic to accompany this article: Check it out!
When it comes to Product, About Pages are all about

connection.
How many times have you come to a new site and immediately looked for an About
Page? I’m willing to bet that for a lot of you, the answer is “frequently." For me, the
answer is “always."
When I look at an About Page, especially for a SaaS product, I’m looking for a few
things:
• How big is the team? This gives a sense for the maturity level of the company.
• What are the titles given to people? This gives a little information on the
company’s priorities.
• Do the employees have Twitter handles? I like to see if their personalities
come through.
• Do they have any big name customers, investors, or partners? Knowing they
have large partners lowers the chance they’re going to fail.
There’s a lot to unpack in that list, but to put it simply, I can usually tell within 30
seconds of looking at an About Page if anyone at the company gives a shit about
their product. If I come away with a “Nope", that’s pretty much the ballgame as far
whether or not I’m going to sign up for their product.
But, when I come away with a “Yup", I get a real kick out of connecting with those
people, whether it’s following them on Twitter, shooting them a personal email, or
just making a mental note to engage with them or their company if the opportunity
presents itself.
I’m not alone in yearning for an About Page when first looking at a new product. Just
look at what I was able to dig up in less than 5 minutes of searching on Twitter:

Amy Ellis, a postgraduate digital publishing student at Oxford Brookes, says she
won’t bother signing up for any service that doesn’t have an about page:
John Sheehan, CEO & co-founder of Runscope, agrees with Wade Foster, CEO &
founder of Zapier, that Breezy appears to have a great site, but still takes time to call
out their lack of an About Page above all else.
Bob Dunn, founder of BobWP, is continually befuddled when a Premium WordPress

Plugin (which is quasi-SaaS) doesn’t have an About Page:

The desire to know and connect with the people behind products is not rare or
fringe; it is core to our humanity.
This is quintessential Product Success

Product Success means being thoughtful even when it comes to what happens at
the product periphery. When you show your customers that you care even at the
‘outskirts’ of your product, they come to trust you more. Being thoughtful about
things like status pages and error pages are two ways increase this trust, and About
Pages are no different.
Having a great About Page will increase your customer's trust in you, which will in
turn make them be more amenable to giving you real insight into what they need in
your product.
There is no downside
Here are some things I’ve heard people say as reasons to not have an about page,
followed by a rebuttal. Feel free to memorize these refutations and recite them as
needed.
“It’ll be easier for competitors to poach our people"
Let’s pop up a few levels here: if all it takes is a recruiter to know your employees’
names and poof their gone, you have much bigger problems to worry about.

“Some new hires are very strategic, and publicizing them could expose our
strategy before we’re ready"
As someone that has never made such a hire, I can’t completely discount this point
of view. However, I will point out that this is a reason to not have a specific person on
the About Page, not a reason to not have an About Page.
“It takes too much time to build and keep up to date"
Really? Take your home page, remove all the copy, add some photos. You can also
use the tools mentioned below like Tumblr or Twitter Lists to jumpstart a lazy About
Page in seconds.
Also, if it really takes a lot of effort to keep your About Page up to date, then you’re
either growing massively, in which case you probably can afford to have a designer &
a developer team up for a day to build a scalable solution, or your company has
some serious turnover issues that should probably be addressed before working on
anything else.
“There’s no ROI in it"
Just ask yourself if you’ve ever checked an About Page before signing up for a new
service. I’ve never met anyone who can answer No to that. If you can answer No,
then please say so in the comments. I’d love to discuss it with you.
A lil’bit’o Ramen data

Here’s a screenshot from our Google Analytics account:

We’ve had a lot of new blog traffic lately relative to the rest of our site, but these numbers still illustrate an interesting point.
Above are some stats for “Goal 5," which is the goal associated with creating a
Ramen account. I created a segment called “About Page," which only includes visitors
who have visited our About Page. In this case, we’re looking at a 5x increase in
conversion rate between those two segments. I know that correlation does not imply
causation, but looking at these data is still interesting. We’re left with three ways to
interpret:
1. Visiting this page made them more likely to sign up

2. Visiting this page means they were already more likely to sign up
3. A mix of options #1 & #2
However you interpret these numbers, the bottom line is people who visit our About
Page end up signing up for Ramen at a rate 5x that of people who don’t. Sounds like
a page that deserves some love, no?

DATA-SCHMATA. Are you really going to listen to a guy who is only getting a 0.38% conversion rate!?
Forget about an About Page, and I guarantee* you’ll get a MILLION PERCENT conversion rate!
#YetiPromises (*Guarantees not valid)

What makes a good About Page?

Separate your Why/What/Who
When you’re all excited, it’s easy to conflate these. Separate them and make
everyone’s life easier:
• Tell us why you started this company and what problems drove you up a wall.
• Tell us what your products are and what they do.
• Tell us who the people are behind this vision and these products.
Not only does Palantir do a phenomenal job at this, they actually tell you that they’re
doing it:
I always want to spell it: “Plantain"
Tell your story
Vision is one thing, but giving your customers a sense to your greater story can go a
long way towards framing their experiences. Moz does a phenomenal job telling
their story. Starting with the founding of the company by Rand and Gillian (Rand’s

mother) in 2004 and going all the way to their 10 year anniversary last year, this gives
you a great connection with their company.
If mom is for you, who can be against you?
Telling the story can also help to set expectations. If you’re 10 years old, like Moz,
that history gives you a lot of credibility with larger companies. Those companies
immediately understand that you know how to support them and that you’ll be
around a while. Being young can be an asset as well. Being upfront about your
company’s youth can attract customers looking to be early adopters of new
technologies. These early adopters, by their very nature, won’t mind giving you some
leeway as you come up against growing pains.
Social Proof can matter
Got some big name customers, investors, or partners? Don’t be afraid to show them
off if you want to. Social Proof gets a bad rap in some circles, but in my opinion it’s
perfectly fine to list them out, as long as mentioning these 3rd parties takes a clear
back seat to telling people about you. In this example, Segment even goes so far as

to link to their open source software projects, a great way to get street cred with a
technically-minded customer base.
A “Metalsmith Socrates Ripple Nightmare" sounds terrifying, but that’s just Segment-slang for their secret puppy room.
Give it some attitude
The rest is up to you. On the About Page for Jirafe–pronounced Giraffe–you can filter
their employees based on attributes like whether or not they are Falafel Enthusiasts
or a Giraffe.

Apparently, their CFunO is not a Falafel Enthusiast.
About Pages at scale

One of the things we said back in the introduction was that we always wanted to
make these articles scalable in the sense that we would make sure to realize that,
sometimes, the “basic" way of doing something doesn’t work at a larger company.
If you’re someone like Hootsuite with over 1,000 employees, an About Page not only
becomes unwieldy (and probably loads very slowly if you’re including headshots) but
it also loses its ability to cleanly convey who the people are behind the different
products.
This led us to ask ourselves: Why do larger SaaS companies tend to limit themselves
to a single About Page? (Tweet this)
There’s no reason that products can’t have their own About Pages. We haven’t seen
this, but I can tell you without a doubt that if I saw a link in the header or footer with

the text “About the Product Team", I would click on it and enjoy learning about the
people behind the product.
The About Page Toolbox

About Pages are pretty static. Modifications are made only when people join or leave
the business, so there aren’t really “tools" for them; you just go make a static page.
However, if you’re looking for some clever ways to avoid that, we came up with a few
for you:
Tumblr
Your About Page could just be a Tumblr where each person writes their own entry.
Using Tumblr’s free subdomains, you could even have about.yoursite.com.
Twitter Lists
You could create a list under your company’s Twitter handle and link to that list, like
this.
AngelList
You can link directly to the Team section of your AngelList profile using the #team
anchor. For example: https://angel.co/ramen#team.
Further Reading
Here are some other posts that will whet your About page whistle:
• http://www.copyblogger.com/how-to-write-an-about-page/
• http://blog.hubspot.com/marketing/remarkable-about-us-page-examples
• http://www.clickz.com/clickz/column/1691484/the-power-about-us-page
• https://www.rocketspark.com/blog/why-about-us-page-so-important/
• https://www.quora.com/What-are-some-of-the-best-company-About-pages
Do you have a favorite about page or have questions? Reach out to us and let us
know!

Part 2: Getting Into A Cadence
In this unit, we’ll discuss some best practices that will be easy to get started with, but
will require some amount of ongoing effort. The best practices in this unit are Status
Pages, Changelogs, and Long-Running Questions (LRQs). The goal of these best
practices is not only to convey information to your customers, but to also convey
that you convey information to your customers. It’s a fine line, but this is where we
really start to establish long running credibility with customers.

All SaaS Products Should Have a Status Page
All SaaS Products Should Have a Status

Page
Status pages have come on strong in the past few years. Conceptually, they’re pretty
simple: a page that communicates the status of an application.
Status pages have a lot of commonalities:
• They can usually be found at the status subdomain, ie.

https://status.letsfreckle.com
• There is usually a bold Red/Yellow/Green visual element indicating the overall
status, giving you an at-a-glance sense for whether or not something is
wrong.
• They contain a list of recent service disruptions.
• They are usually completely public; you don’t have to login to see it.
We’re talking about status pages today because every single SaaS product should
have one. Status pages have become pretty common, but their not perfect yet. This
post will explore why you should have a status page, and how to get one quickly set
up with the goal of giving you the ammo you need to finally set one up.

Why all SaaS products should maintain a status page
Pretty much any website, from blogs to e-Commerce, could justify having a status
page. But the bar gets raised when we’re talking about a SaaS product. There are a
lot of benefits to having one that extend far beyond “just communicating status."
1. They reduce customer frustration
First, and most obviously, status pages are great because software it super
complicated, and it breaks in really annoying ways all the time. A ‘simple’ SaaS
product today can rely on dozens of 3rd party services. Some of those 3rd-party
services are critical path, and if they go down, the app goes down. SaaS products are
either in the cloud, or in the case of native mobile apps, rely on APIs in the cloud.
Clouds break too.
For a SaaS customer who might be logging in for that one time a month to push the
button that gives them whatever it is they pay you $5k/month for, telling them “Hey
we’re down because of XYZ right now. Hope to be back in 30 minutes" is much
preferable to having them sit at their computer freaking out thinking their Internet
connection is down for half their morning.
2. They increase customer confidence & help manage expectations
Some product people we spoke to worry that status pages can decrease customers
confidence because it highlights mistakes. We’ve seen the exact opposite. Status
pages demonstrate to customers that you care. How you describe disruptions, their
root cause, the fix, and the steps you’re taking to ensure they don’t occur again is
one of the best ways we know of to gain your customers trust.
Furthermore, status pages help to manage expectations. Software is not perfect, and
nobody should be under any delusions to the contrary. Having a status page says to
your customers “look, things are going to break. it happens. but when it does, you
can see by our track record that we bend over backwards to make things right."


Everybody knows that customers expect software to be available 100% of the time! If you have a
publicly available status page that lists out all your faults, people won’t trust you and will think your
product is crap. Better to keep all that stuff secret so your customers think your product is perfect all
the time!
3. They encourage customers to report errors & poor performance
Check out this Twitter search for ‘but “your status page"’:

Not gonna lie: We did not expect this many examples when I did this search.
Diving into one of the tweets, we see an interaction between Intercom and one of
their customers:

Nobody wants their customers to be doing QA, but having them help you out from time to time is a plus.
And if we click the stspg.io/1YM5 link that Intercom tweeted right after that, we see:

Well, look at that…. That tweet caused them to create an incident.
So it turns out that the incident on their status page was created because of a
customer report on Twitter. Pretty cool.
And did this interaction frustrate the customer? On the contrary:
I don’t think Chris is canceling his Intercom subscription any time soon :)
Sounds like Mr. Davis is pretty happy.
Status Pages not only increase trust, but increase communication between customer
and product team. If you don’t have one, get one :)

How SaaS products can (and should) use status

pages
So you’ve decided to put up (or start properly using) a status page. Awesome. Here is
a list of ways we’ve seen companies successfully use status pages. One thing you’ll
notice as you go down this list, is that each item requires more work than the last. As
such, as you go down the list, they become more rare.
1. Notify of service disruptions
Whenever there is an incident, create an entry. Be sure to include the time it started,
an explanation of how it is manifesting and where (eg. “intermittent 502s on web
app" or “API completely down").
As the incident matures, edit that entry with updates on what is happening, taking
care to include timestamps of each update and any available ETA.
When the incident is resolved, mark it as such, either using a tag or putting
“[RESOLVED]" at the start of the title.
2. Notify of planned or possible outages
Use your status page in combination with some kind of in-app notification or mailing
to notify customers of impending downtime. This could be when upgrading
hardware that will result in known downtime, or software updates that are larger
than usual and should go smooth but might not.
3. Provide retrospectives (also called Root Cause Analyses)
Provide a “retrospective" on larger incidents. Take the opportunity to provide greater

detail on what happened, how it was fixed, and what steps are being taken to help
ensure it doesn’t happen again. These retrospectives can be just be an addendum to
the incident entry, or you can create new entries in your status page that link back to
incident in question.
Some companies will send out emails to their entire customer base when there are
huge outages. This is awesome, but be careful to not let all that work writing your

retrospective “die" in a one-time email. Put it in your status page so that future
customers can see how seriously you take things.
4. Proactive notifications via email, SMS, or push
Tie your status pages incidents into a system that proactively notifies customers
when things happen. These messages can go out via e-mail, SMS, or even push
notification if you have a native mobile application.
This obviously has it’s limits. If your product has 400k customers, 20k of which log
into the web-app per month, 200k of which are idle, and 180k of which simply get an
email report from you once a day, you don’t really wanna email 400,000 people if
there’s a hiccup in the website as it doesn’t affect all of them.
I’m not proposing a solution for how to manage the above case, but I
wanted to call to attention that some of the things we’re talking about
here are a lot more nuanced than they may seem at first.
5. In-app integration
I hadn’t actually seen this until Freckle, but they put a little dot right in their app. This
is awesome, because it removes the need for a customer to through the following
exercise:
1. Have a bad experience

2. Think to themselves “Gee I wonder if something is wrong".
3. Go hunting for your status page.

All. Systems. Operational. Geez, Freckle. You adorable.
6. Oopses
We don’t see this one much, but status pages don’t have to just be for service
disruptions or outages. Every now and then, people screw up. A mailing goes out
that wasn’t supposed, or someone tweeted something stupid from their phone
forgetting their Twitter client was on the company account.
This actually happened to Ramen in September 2015. We sent an email out by

accident, and instead of sending another email out, we just put an incident in our
status page. Status pages are a perfect place to put this kind of stuff. It conveys
humanity, and lets people know that “no, we did not intentionally send you all that
random email".
Status Page Tool Box

Here are some great free/hacky options, a great open source option, and a
phenomenal 3rd party product you can pay for to help get you started with a Status
page in minutes.

Tumblr
Tumblr is a great, free solution for a status page. Their infrastructure is stable,
redundant, and can handle major traffic. People can ask you questions and
comment on posts as well. We use Tumblr for Ramen’s status page, and we just
change the color of the title text whenever we need to. They even support custom
domains, so you can still have that status subdomain like we have for
http://status.ramen.is. They do not, however, support SSL, so if customers stumble
across https://status.ramen.is, for example, they will think you have no status page.
WordPress
WordPress is also a great, free option. One advantage WordPress has over Tumblr is
that people can subscribe to email notifications on new incidents. You’ll need to be
mindful of how you deploy WordPress. If you deploy it on your own infrastructure, it
could go down along with your application during a service disruption.
WordPress.com provides free hosting, but if you want a custom domain, you’ll have
to pay.
You’ll also want to be careful to make sure your installation has enough horsepower
behind it. The thing about a status page is that it requires zero resources until
something goes wrong, and then it needs to handle massive traffic. If you go this
route, and do a self install, do yourself a favor and setup a CDN & page caching with
plugins like W3 Total Cache.
Stashboard
Stashboard is a project that came out of Twilio in 2010, and has cemented itself as
the go-to open source purpose-built option for status pages. It’s built to run on
Google App Engine, so there is a generous free usage tier, and unless your
application also runs on GAE, it’ll stay up even when your entire hosting
infrastructure goes down.
StatusHub.io
StatusHub provides hosted status pages for a reasonable price.

StatusPage.io
StatusPage.io has cornered the market on hosted status pages over the past year.
With a keen, product-focused eye, they’ve built a great product that addresses all the
rough edge cases that make status pages a lot more complicated to implement than
appears at first glance.
They don’t have a free tier (although you can play around with their product and
view your status page privately for free), and their cheapest pricing tier is $29/month.
This is a steal if you have any revenue at all, but the lack of a free tier means you
might want to start out with one of the free options above until you grow a bit more.
At scale (re: Enterprise) they have a bunch of great solutions for private status pages
as well, which can be important if the application your reporting status on is an
internal-only tool.
Disclaimer: The Status Page people have an awesome product and are
personally awesome. We know this because they work down the street
from us. However, that had no impact on being listed here.
In the Wild
There are a ton of great companies using status pages including:
• Amazon Web Services

• Apple
• Freckle
• Intercom
• StatusPage -- so meta
If you don’t have a status page for your SaaS product, I hope we’ve convinced you to
join the ranks of these great companies.
Have a great example of a Status Page or have more questions? Shoot us a note:

6 Reasons Companies Like Customer.io
& Intercom.io Spend so Much Time on
Their Changelogs
The term Changelog (aka Release Notes) has been around in the software
development world for a long time. There, it is a list of changes to a piece of
software. It is usually associated with a particular “release" and ordered
chronologically. Here’s the Changelog for an open source software project called
Sidekiq.
Changelogs don’t have to be that nerdy (Tweet this), however. In SaaS world, many
successful products like CustomerIO and Intercom have taken the idea of a
Changelog and applied it their products. They regularly publish updates on the
changes they make, why they made the change, and explain how the change will
affect customers.

6 Reasons Companies Like Customer.io & Intercom.io Spend so Much Time on Their Changelogs
Anyone who has ever produced content can look at the example above and
immediately tell that these are not quick posts. They take a lot of time. These are full
blown blog posts with collateral and editing.
Why do companies spend their time on this? Why do we agree that they should?
Because Changelogs are super important for a lot of reasons.
Why are Changelogs so important?

Reason 1: It informs customers what is changing
What good is fixing a bug if nobody knows about it because they’ve been avoiding
“that buggy part of the app"? What good is a new feature if your existing customers
don’t even know it’s there?

David Cancel and the team at Driffft have been blogging lately that the future of
marketing is marketing to your customers and not strangers. They call it Relationship
Marketing.
And they’re right. Changelogs are a part of Relationship Marketing. (Tweet this)
Reason 2: It informs customers that there is change
How many times have you came to a new SaaS product website, saw their last blog
post was 6 months ago and their last tweet was 4 months ago, and thought to
yourself “NOPE"?
Customers like knowing the lights are on even if the things being changed are not
something they’d use.

But customers are like children and they might get mad if other bugs get fixed before their bugs. Better
to stay completely silent and never risk getting anyone annoyed.
Reason 3: It shows prospective customers how you communicate
For people like myself, an awesome changelog can make someone fall in love with a
product before even using it. Changelogs are an opportunity to explain how you
think about your product. (Tweet this) It might not be a sexy marketing tag line that’ll
convert you a billion users at a 90% conversion rate in 3 days, but it’ll make the
astute reader respect the hell out of you, your team, and your product.

Intercom’s changelog includes thoughts on how and why one might want to use the new feature.
Reason 4: It forces your product team to think about things

discretely
It’s a sign of maturity when a company is thinking about what they’re changing in
discrete chunks. CustomerIO recently released version 5.5.12. Ok. These guys aren’t
some young pups. They’re not screwing around. They are rigorous. I trust them.
Reason 5: It sets expectations and fosters accountability
“We released XYZ" - Company
“Oh really? XYZ is crap and doesn’t work in IE at all" - Customer comment
Just like email receipts are awesome because they make your customers ask
themselves “do I really need to pay for this?" (which, trust me, you really do want
happening) Changelogs are awesome because they make your customers think “oh

ok cool that’s out now, I expect that it’s ready for me to use, and I’ll complain if that
expectation isn’t met."
You want these complaints.
Reason 6: It shows you care, and encourages your customers to

reciprocate
Finally, we circle back the definition of Product Success: Product Success is about
being thoughtful when it comes to what a product does at the periphery — outside
the core product — and how those peripheral interactions foster an environment
through which many direct and indirect forces carefully nudge the product to get
better and better over time.
Setting up your own Changelog

Intercom and Customer.io both made their own, custom Changelog but that’s not
required. Setting up your own Changelog can be pretty easy. Here are some tools
you can use to hold that content:
Tumblr & WordPress
It’s interesting how many times a thematic, well-maintained Tumblr or WordPress

blog can quickly and cheaply solve a problem, and that’s the case here too.
Remember, at the end of the day, the Changelog is really just a series of entries listed
chronologically.
Knowtify.io
Knowtify has a bunch of different tools, but one of them, called Inbox, can be used
for new feature notifications: http://www.knowtify.io/inbox
Ramen
We started Ramen with the idea to help SaaS product people be successful, and as
part of that we built something we call “Product Center". Product center allows you
to share product ideas and updates, as well as getting your customers to comment
on them. You can try out Ramen for free.

Have you seen a great example of a Changelog, or do you have more questions
about setting up your own Changelogs? Ask away:

What Are LRQs and Why do All SaaS
Products Need Them?
Today we’re talking about “Long-Running Questions" or LRQs. LRQs are something
that every single SaaS product should utilize. No exceptions.
If you’re reading this in 2015, and you just you took a break to go Googlin’ for “LRQ",
you’re probably not going to find much. That’s because we coined this term internally
at Ramen and this is the first time we’re using it publicly.
An LRQ is a single question that you ask your end users, either in-app or via email, as
part of the natural course of their usage of your product. LRQs all share a few
characteristics:

What Are LRQs and Why do All SaaS Products Need Them?
• They are composed of a single question. “Take 5 minutes to answer this

survey" is not an LRQ, it is awful.
• They are asked of logged in users. “Would you like to chat with a sales rep?"
is not an LRQ.
• They are asked automatically. Users are automatically asked at predefined
points in their customer life-cycle.
• They are asked continuously. Sometimes for the entire life your SaaS
product.
• ** They are “long running" from your perspective.** LRQ responses are
reviewed regularly with a specific eye towards monitoring changes in how
customers respond over time.
• Their purpose is strategic rather than tactical. The goal is to monitor the
overall health of a customer base over time while leaving a little leeway for
serendipitous discovery.
The most popular LRQ is NPS (Tweet this)

Most of you probably knew where this was going right off the bat. Net Promoter
Score, or NPS, is by far the most popular–and to my knowledge the only rigorously
defined–LRQ.

How NPS works
You start off by picking two interval periods: initial and ongoing.
1. After initial days, you ask your customers the following question:
"How likely is it that you would recommend Ramen to a friend
or colleague?
2. After answering, the customer is usually prompted to “Tell us
more about why you chose X" in a follow up question, but that’s
not required.
3. Every ongoing days after that, you ask your customers the exact
same question.
4. Every day, take all the responses–ignoring any people who
dismissed the survey without responding–and do the following
math:
◦ If they answer 9 or 10, label them as a Promoter.
◦ If they answer 0 through 6, label them as a Detractor.
◦ If they answer 7 or 8, label them as a Passive.
5. Get the % Promoters by dividing the # of Promoters by the total
# of responses
6. Get the % Detractors by dividing the # of Detractors by the total
# of responses
7. Subtract the % Detractors from the % of Promoters, remove the
% sign, and you’re left with a plain old scalar number between
-100 and 100. This is your Net Promoter Score.
Net Promoter Score is just that: a score. It’s not a percent. There are not passing and
failing grades. 60 isn’t necessarily good and -10 isn’t necessarily bad. People who talk
about “needing to bump their NPS up a few percent" are not only using the wrong
terminology, but they’re probably thinking about it all wrong to begin with.
What’s really important with NPS is how it changes over time. See the NPS start to
tick up recently? You’ve probably been doing something good.

This previous statement is actually at the core of why some people

dislike NPS. Lots of things change in software all the time, and reducing
everything down to a single number is seen as not only over-
simplifying, but potentially misleading.
A new marketing initiative that goes after a brand new persona, for
example, could cause a flood of new, really excited customers into your
product. But if, 45 days later, it turns out that the language in the
marketing copy incorrectly led people to believe that you had a certain
set of functionality that you didn’t, they’re going to churn at very high
rates. In this pathological example, you could have changed nothing in
your product, and still over the course of 8 weeks seen a spike in NPS
followed by a spike in churn.
This makes NPS seen as misleading/dangerous/etc by some.
Opinions on NPS aside, LRQs are a vital tool for product creators
Whether you love or hate NPS, it’s important to remember that what really matters is
that you have some set of LRQs to act as a proxy on the pulse of your customers’
attitude towards your product. Every SaaS product should have at least one (but we
could make an easy argument for three) active LRQs that they look at every week.
What matters is that you regularly look at the results and start to get a “feeling" for
the data.
What makes an LRQ
Before we get into what types of LRQs you should be asking, I want to talk about two
distinct “families" of LRQs: one-time and periodic.
One-time LRQs are asked transactionally. (Tweet this) Examples include right after a
user signs up, after they’ve been a customer for a certain amount of time, or after

they’ve completed a certain workflow. The idea here is that the customer is only
asked the question one time.
Periodic LRQs are asked repeatedly (Tweet this) They are asked initially after a certain
amount of time, and then at a regular interval thereafter. A valuable characteristic of
periodic LRQs is that you can monitor for customers that change their answers over
time. NPS is a periodic LRQ.
Because of the repetitive nature of Periodic LRQs, there is a lot of nuance to how
they are implemented.
Periodic LRQs are “rolling"
They need to be asked in a rolling fashion, so you don’t have a “survey day" where
you ask everyone that logs in on a certain day the question. This opens you up to
several biases. If the majority of your customers are in SF, and the Giants lose an
NLCS game in extra innings late last night, your customers might not be in a super
good mood, and that can really affect your numbers.
Periodic LRQs aren’t for brand new customers
Unlike one-time LRQs, periodic LRQs are rarely asked of brand new customers, as
the context of their answer will dramatically change by the time they answer the
second time. You want to give them time to reach a “steady state" or else you’ll
always see huge changes in their answers once they start getting the question for
the second time.
Periodic LRQs are asked “for no reason"
Let’s say you want to establish an LRQ to monitor the “health" of your checkout
process, and you set it up so that the question will appear after your customers
finishing buying something. You don’t want to survey them every single time, so you
set up the question to only be asked if it’s been 60 days since the last time they were
asked.

However, in this scenario, you’re only asking people the question after they’ve
successfully completed a transaction. Maybe your process isn’t actually very good.
Maybe your workflow is so confusing that people abandon in many cases. I’m
painting a pathological picture here, but it illustrates the point that randomly asking
customers who have completed a checkout process:
Hi Matt, Over the past few months, have you found our checkout process to
be a satisfying experience?
Is much different than asking them right after they finishing buying something.
Example LRQs
Ok, if you’re still reading, bravo. This is what you’ve been waiting for. Below, we’re
going to go over some LRQs that you can start asking right now, and follow up with
some tools to help you do it.
One-time LRQs include questions like:
“How did you find us?"

Answer: Multiple choice (which is preferred and will change based on your
product) or open-ended
When to ask: As soon as they complete the signup flow
“What are your first impressions?"

Answer: Open-ended
When to ask: Once the customer has had a chance to get a first impression.
This could be within 10 minutes of signing up, or could be after a week. It all
depends on your product.
Periodic LRQs include questions like:
“How likely is it that you would recommend Ramen to a friend or colleague?"

(NPS)
Answer: 0-10
Follow-up question: “Tell us more about why you chose that"
Follow-up answer: Open-ended

When to ask: Depends on your product, but Ramen asks our customers
after 30 days and then every 60 days thereafter
“Anything frustrating about the app you’d like us to improve?"

Answer: Yes or No
Follow–up question: “Tell us more"
Follow–up answer: Open-ended
When to ask: Up to you, but Ramen asks this question every 45 days.
Should LRQs be asked in-app or via email?
This is a tough one. For most SaaS apps, in-app gets you a lot further, as questions
can be asked in context. This allows them to be shorter. It also affords much higher
conversion rates. We’ve seen in-app response rates around 40%, where email
response rates are ~ 15%.
However, many products have usage patterns that make in-app not super useful.
These include situations where your customers don’t interact with the product in
their browser frequently, but maybe simply enjoy a daily or weekly email. In this
case, you probably want to lean towards email questions.
Analyzing LRQ Results
Once you start asking these questions, you have to do something with all those
amazing data. You’re technically inconveniencing your customers by asking them
these questions, so make that worthwhile.
Get into a regular cadence of reviewing answers to questions. Get a weekly email
setup that sends you the following for all your LRQs:
1. New answers last week

2. Answers from last week
3. Answers from all-time
Obviously you want to see the most recent answers, and you probably want to see
answers from all-time, but you’re going to also want to compare the most recent
answers with the precedent time period (read: last week vs. two weeks ago)

For periodic LRQs, your weekly report should include the number of people who
have changed their answers since the last time they answered. This is a lot easier
said than done, and in most cases will require some custom development on your
end.
The LRQ Toolbox

This week, we’re going to break up our toolbox into sections: E-mail and In-app. For
earlier stage companies, or businesses without a strong technical person, email will
probably be a lot easier to setup (unless of course you’ve already installed
Segment.com and want to use Ramen ;)).
Email
• SurveyGizmo & SurveyMonkey – Both offer free tiers and make it easy to send
surveys via email.
• Delighted & Promoter.io – Very similar products that provide an email-only
NPS solution. However, as of writing this, their free tiers are not very
generous.
In-app
• Wufoo & Google Forms – Wufoo & Google Forms can do a lot for free.
Although the UI of popping up an iFrame w/ a Wufoo/Google form would
leave a lot to be desired, and it would leave you to do all the NPS math on
your own.
• SatisMeter – A very straight-forward tools for implementing in-app NPS. They
have a free tier, but it’s not terribly generous.
• Intercom – Intercom can be shoe-horned to do this, but you’ll have to do all
the math on your own.
• Ramen – Here’s the thing: the lack of a proper solution to do this is pretty
much the reason I started this company. So, I’m not going to belabor the
point: we have NPS and generic LRQ support, and I’ll just leave a little link
here in case you want to try Ramen out. TL;DR: These LRQs are tough to get
right, and as you can probably tell from this extremely long-winded chapter,
our team has spent a lot of time thinking about it.

Those options are way too much work or too expensive! Ain’t no Yeti got time for that! Forget
everything you just read and just keep building your product without any of these EL ARE QUEUE things
this dude is talking about. Too much work. #Grump
In the wild
Here are some great examples of companies using LRQs
Mention.com
Mention.com has extensively used NPS to decrease their churn. Here is a

presentation their head of growth, Guillaume Cabane, has done on the topic.
After reading a draft of this chapter, Guillaume had some great comments which he
gave me permission to post here:
We discovered that you can’t handle answers from your free and paid users
the same way. And if you do, you shouldn’t. Because someone paying you
hundreds of dollars a month and leaves a text comment, that needs to be
handled by a human being.
Never lie to your customer. If he thinks (because you smart marketer let him
believe that) there is a human being reading / replying to his survey, then
you need to be able to handle the volume of answers. We generate north of
1,000 NPS surveys per month at Mention, and though it’s some work, it’s
definitely worth it.
SugarWOD
SugarWOD has a native mobile app for tracking CrossFit workouts. They also have a
web UI for gym owners to schedule workouts and monitor their athletes’ progress. A
question they’ve had in the wild for a while is about getting first impressions:

SugarWOD with a quintessential LRQ
Drew Larsen, founder & CEO of SugarWOD, highlighted this answer as one of the
most interesting so far:
“So far an excellent program. Before looking at investing I am waiting to see

what kind of following this will gain in my gym."
Drew said that: “Knowingly or not, this guy shared with me his biggest concern /
objection / trial criteria. I followed up with some rollout tips, some stats on what kind
of adoption to expect and created a “to do" to follow-up with him on this specific
topic after a week."
Another piece of feedback that Drew received from this LRQ:
“Hey guys – quick question. Do you see this platform expanding to emulate
services as seen on WodHopper, Wodify, FrontDesk, ZenPlanner, etc?"

From Drew: “This prospect is asking if we are going to provide complementary tools
from an adjacent software category. We’re not, but it was really helpful to know so I
could pro-actively address his issue. He is now a customer."
Final Thoughts on LRQs

I hope you found this chapter helpful. These types of questions are hugely beneficial
to product creators, and I urge you to start asking them regularly through whatever
means available to you.
Have questions about what types of LRQs you should be asking in your product?
We’re all ears and happy to provide some feedback:

Part 3: Architect for Success
Part 3: Architect for Success

In this unit, we’re going to talk about best practices that may require significant
overhauls to your product or your internal business processes, but that have been
shown to increase the probability of success time and again. This includes things like:
mobile-first design of your entire product, along with implementing and supporting
in-app chat.

Delight Your SaaS Customers with a
Mobile-First Product
Let’s dive into a topic not unfamiliar to many of you internet gurus these days,
mobile-first design. The idea of mobile-first is pretty simple, but the result of
implementing this in your product has larger reaching implications beyond you site
just “working on all devices". I’m not here to spit out a bunch of statistics about why
mobile is the next big thing, you can find those elsewhere.
So What is Mobile-First Design?

Historically, most web applications prioritize the “Desktop" user experience, and
leave the mobile user experience as a secondary feature to complete later. In recent
years though, the industry trend has been to flip the design approach to mobile-first
and work up to desktop versions.

Delight Your SaaS Customers with a Mobile-First Product
To take that one step further, it’s just as important to design for any screen size
between a small phone to desktop. Screen sizes changes all the time and your
product should be ready to adapt.
Your product needs to go where your customers go

Ease of use is a key factor for new product adoption these days. When evaluating
new products and tools you can bet the average SaaS customer will be looking to see
if your product works on mobile.
We’ll use Trello as an example. Here you can see their dashboard used to manage
projects and organize anything. It would be safe to assume a majority of usage
comes from desktop users.

However people on the go also need to stay organized and access their content so
having a simple experience translate from desktop to mobile makes everything work
together and keeps customers happy.
Surprisingly a lot of the functionality is left in but the UI is simplified for mobile.
I can’t tell you how many times I forgot to do something in an application on my

desktop and visited the site on my phone to find that they only made it “just work"
on mobile.. but have a sub-par, clunky experience.


Don’t make the effort to build your website for other devices. Rotary phone sales are sure to pick back
up.
Mobile-First design makes a product stronger

Product Success is about what happens on the product periphery to make the
overall experience for your customers better. There are a few key benefits to mobile-
first design that may not be outright obvious to product creators.
1. Establish product credibility
First impressions matter more on the web than anywhere else. If your product
doesn’t present a professional look on mobile, your customers will assume your
product isn’t up to snuff. If you’ve made effort to make your website responsive and
delivers the right experience at any screen size your customers will notice.

2. Promotes solving problems for a streamlined experience
When designing mobile-first you are forced to focus on core content and
functionality. With limited space you better deliver the functionality your customers
need up-front and easily accessible. When done right this translates to making your
desktop service just as usable if not more so.
Take MailChimp as another example. When you view MailChimp on a mobile device,
you are presented with the information you need and not much more.

When we bump up in size to desktop we add in more features like ordering, mutli-
select options, filtering and other features that are “nice-to-have" but not essential
for mobile users.

3. Forces you to think about the job to be done
When you think about how your customers will use your product and in what
context you focus on what is important to them. You will discover what is really
useful and what features might be left unused, clunky, and not fail to add tangible
value.
Taking a simplified approach to your product and content from the start helps keep
your product lean and flexible. Have you heard the phrase “If I had more time, I
would have written a shorter letter?" For mobile let’s translate that to “If I had more
time, I would show the user less“.
Toolbox
Building your site mobile-first is more about the process than the tools, but here are
some things to get you started.
Getting your feet wet with a grid systems
Implementing a grid system is a relatively easy first step towards being mobile-
friendly if you already have an established website and style set up.
I’ve personally used grid systems like 960.gs and Less Framework 4 to help move
clients into a more standard, structured site. Check out the latest grid systems here
and make your choice wisely.
Starting from scratch with a framework
If you are starting your website from scratch it’s probably in your best interest to
start with a framework that has the bells and whistles for mobile ready for you. Just
remember these are meant as a starting point, any good product will change to fit its
customers needs.
Probably the most widely used Frameworks are Twitter Bootstrap, HTML5
Boilerplate and Foundation. Check out other frameworks here.

Closing thoughts on thinking mobile-first

Mobile-first design thinking is bigger than frameworks and layouts, because as I
mentioned above it’s not just about the implementation. I challenge you to think not
just mobile-first, but how you can exceed customer expectations on any screen size
using the right interactions.
Click the green R below to share your experience with mobile development. How has
it helped you improve your customer experience? Did you see improved conversion
or less churn after switching to a mobile-first approach?

7 Keys to Making In-app Chat Work for
SaaS Product Success
In previous chapters, we tend to wax poetic about the WHY of a thing before getting
to the tactical bits in most of our posts. In this chapter, we’re going to mix it up a bit.
We’re going to get straight to business, then we’re going to make some potentially
controversial statements without being too long-winded about it.
1) Appoint a Chat Czar
For a small team, having people rotate through “in-app chat duty" and then come
together once a month to discuss what they’re seeing is easy. At scale though,
managing in-app chat can be super complicated to get right. This is why it’s
important to not just “throw in-app chat into the app and route them to customer
support." A Chat Czar not only establishes the processes for managing in-app chat at
your company, but they’re the ones who will periodically review chats to keep a
subjective finger on the pulse of what’s coming through chat. This person will usually
just be the Product Creator (or Product Manager, or Owner, etc…) but it’s worth
thinking about this as another title. It’s that important.

7 Keys to Making In-app Chat Work for SaaS Product Success
2) Take the time to test and choose the right tool for you
Like many things, in-app chat is simple in theory but incredibly complex in practice.
Each tool has nuanced differences that can make a huge difference in how it works
for you, so if you’re not already using one, take the time to try a few out and see
what works for you. There’s no reason you have to do your due diligence in a
vacuum. Install one for two weeks, switch, move on. If you’re a Segment.com
customer, it’s super easy to install and switch between tools like LiveChat,
LuckyOrange, Olark, SnapEngage, Userlike, Intercom, Zopim, and more.
3) Manage response time expectations
Nothing is worse than sending a message off into the void and wondering when it’s
coming back. Nothing, that is, except getting something back that is ambiguous. How
many of you love hearing “cool I’m gonna get to that soon" when talking to a friend
or coworker? “Soon" can be 5 minutes or a week. Manage expectations by ensuring
that your users understand what timeframe to expect a response in, and what times
you are in the office. Also: Use timezones, people! The world is not flat, and your
users are not at most 3 time zones away anymore.
4) Sign your automated responses as automated
Everyone loooooves setting up automated responses, but how many of you have
sent a real email or chat to someone and found out later they didn’t respond
because they thought it was automated? Messages can be both personal AND
automated. Let your customers know the difference.
5) Respond when you read it
Respond. Even if it’s a “huh. cool just read this. we need to think about this. I’ll set a
reminder to ping you in two weeks once I’ve had a few hallway conversations with
people about this" People don’t mind that. They’d rather that than:
• Get no answer ever

• Get no answer for 6 weeks
• Get a canned answer about how “their suggestion was awesome and it’s
being forwarded to the product team"

Why waste your time with In-App chat? Your customers don’t have anything valuable to say and you will
be overwhelmed with spam.
6) Have regular ‘chatrospectives’
To be successful, you need to regularly review what’s coming in through chat.

Otherwise you’re just doing a lot of work for no reason. Make the effort you put into
chat measurable by tying it directly to improvements in your application. To make
this happen, have regular “chatrospectives" — believe it or not, that’s a made up
word — where you go over feedback and decide one thing to change/build/improve/
deprecate based on those discussions. Obviously, the Chat Czar runs
Chatrospectives.
7) Tell people about what you get out of chat
Whatever comes out of your chatrospectives should be publicized. Write a blog

about it. Setup an automated chat message to inform them about it. Use Ramen
alerts to notify them in app. Whatever you do, your customers should know that
“December 2015’s Chatrospective improvement is XYZ". Even if it’s small, your users
will love seeing this. Yes, you might get people complaining about why their
complaint wasn’t the one that was fixed, but every complaint is an opportunity to
surprise someone.
Let us know how you succeed with in-app chat

These 7 keys to making in-app chat work for Product Success come out of years of
experience working with dozens of software companies. Do you have any other best
practices that increase in-app chat’s efficacy? Let us know:
Why this matters for Product Success

Let’s get a little long winded about why this stuff matters for Product Success. As
we’ve said many times before, PS is about the periphery. Most Product Creators are

7 Keys to Making In-app Chat Work for SaaS Product Success
experts in their field. They know the domain of the product inside and out, but a lot
of times customers will interact with your product in ways that are more boilerplate.
We’ve talked about these things before: Status Pages, About Pages, E-mail receipts.
In-app chat is no different.
Simply establishing the fact that you are available makes your customers feel better.
It makes them not just view the product as some pixels on the screen, but as an
extension of the people behind it’s creation: you.
As Product Creators, we don’t need to (and in fact could never possibly) establish
deep relationships with each customer, but we can establish a relationship where
our customers know that “Hey building stuff is a super tough multivariate
optimization problem, but we’re listening, and we deeply care, and we’re doing our
best." Having in-app chat and doing the 7 things above goes a long way towards
conveying that message.
Still not convinced that in-app chat is the way to go, or want to recommend another
company for inclusion in our next edition? Click and let us know:

Conclusion: It’s all just a long
discussion
As we said in the beginning, we’re not trying to say everyone who isn’t doing these
things is incompetent or doomed to failure. We’re just highlighting some interesting
trends that everyone seems to be experiencing but nobody seems to be talking
about very directly.
It’s our hope that you all give us lots of feedback via the little Rs: and we’re able to
put out a second edition or a whole new eBook later this year with more stories,
data, and best practices.
It’s been a blast writing this book. Thanks for reading. See ya’ll on the Internet.

Thanks!
Thanks!
We’d love it if you could share this with friends :)
Share on Twitter (Tweet this)
Share on Facebook
Share on LinkedIn

Shameless Plugs
Check our products:
Ramen
Ramen is a product that helps you learn what your customers need by enabling you
to ask simple, yet highly-targeted questions of them while they use your product.
ChartURL
ChartURL lets you create personalized image charts that can be easily embedded in
emails, Slackbots, PDFs, and more.

Credits
Credits
Huge thanks go out to everyone who played a role in this book either by giving
feedback on process, reviewing chapters, or simply providing moral support.
• Nick Sutterer
• Rachel Andrew
• Kimberley Byer
• Mike Lewis
• Steve Klein
• Weston Platter
• Ben Nunez
• The Foundry Group Executive Mailing List
• John Mayfield
• Drew Larsen
• Guillaume Cabane
You all rock. I award you all a cat GIF.

Appendix: Creating Successful SaaS
Products
This is a slightly modified version of the original introduction to the

Creating Success SaaS Products Blog. We’re including it as an appendix
because, although we feel it’s an interesting piece of writing, it didn’t fit
with the overall flow of the book once we started to edit it. We hope
you enjoy reading it!
“How do I create a successful SaaS Product?"
If you’ve ever asked yourself this question, you’re not alone. We’ve spent years
thinking about this question, and after talking with a lot of very smart people about
how they approach it, we decided to create this blog series to look at this question.
Every week through the end of 2015, we’re going to share and discuss tactical,
scalable best practices for Product Success: a topic that lives at the intersection of
Customer Development, User Experience, Customer Success, Product Management,
and Customer Support.

Appendix: Creating Successful SaaS Products
SaaS Product Success Best Practices

For the purposes of this blog series, a best practice will always be:
• Tactical — It will be something you can look at and objectively answer the
question “are we doing that?" with a definitive yes or no.
• Scalable — It will be something that is just as beneficial to a solo founder as it
is to a SaaS Product Creator at a 1,000 person company.
• Hackable — You’ll be able to implement a lot of these best practices by paying
a 3rd party to do the heavy lifting, but there are always hacks, and we’ll make
sure to show you great ways to get things done on a dime.
The first best practice we’re going to explore in this series is Error Pages. In that
post, we’re going to discuss how most Product Creators are missing out on a golden
opportunity when it comes to how they use their 404 & 500 pages to learn from their
customers.
Other best practices in this series will include things like:
1. Mobile-first design for non-mobile reasons

2. The importance of status pages
3. Why in-app chat is vital
4. How Changelogs make customers trust you more
In each post, we will talk about how the best practice is much more than it seems on
the surface, and enumerate ways you can easily get started. As you’ll come to see, a
common theme among many of these best practices is around establishing higher
quality feedback loops (ie. Lean Startup 101: Build -> Measure -> Learn), as raising
the level of discourse between customer and product team is at the core of Product
Success.
This this book is cool? Share it with a friend.
Why write this book?

Ever since playing Mammoth Hunter in my dad’s office at age 7, I’ve been enthralled
by exploring ever more complex systems in software, technology, product
development, and entrepreneurship. I’ve watched, read, and learned as entire

categories of thought have emerged, evolved, and matured. Things like Agile, Lean,
Customer Development, User Experience, Customer Success, and Growth Hacking. If
you’re like me, you’ve read all the books on those topics, turned the last page over,
and thought:
I’m gonna agile-y manage the leanest, most customer-developed product

ever!
If you’re really like me, you then sat at your desk and looked at an empty whiteboard
for a few minutes before cracking open a new browser tab:
I can’t believe what a bunch of nerds we are. We’re looking up “money laundering" in a dictionary.
-Peter Gibbons in ‘Office Space’.
The results you get back contain references to things like Lean, Agile, and Customer
Development among others. These approaches are based on the scientific method,
thereby making them virtually unassailable methodologies from a logical
perspective. Their greatest strength — that they can be applied to any department in
any business — is also a weakness.
This general applicability means that the body of work around these topics tends to
be fairly strategic. Once you wrap your brain around the methodologies, many of us
are still left wondering, “So… what do I do now?"

Creating Categories
As the size of the software industry expands, what were once edge cases for a few
become the status quo for many. As this happens, bodies of work start to pop up
exploring these edge-cases-turned-status-quo in ever-increasing depth until they
eventually reach the stage of Category.
The image below is a screen capture of Google Trends for a few Categories that are
familiar to you. It’s amazing to think that 5 years before writing this, nobody was
talking about “Social Media Management" or “Customer Success". Even more
shocking is the absence of “Growth Hacking" until late 2012.
You think that’s crazy? The iPhone didn’t exist 400 weeks before writing this post. That is still B-A-N-A-N-A-S to me.
This doesn’t mean people weren’t managing their social media before 2010, or that
people weren’t coming up with clever ways to hack growth before 2012. People just
weren’t labeling these activities as such yet. Eventually, a critical mass is reached, and
these things were labeled. The labeling made these categories something to be
focused on, discussed, debated, and refined.
Over the past couple years, we’ve all seen this happen in categories like User
Experience, Growth Hacking, Influencer Marketing, Content Marketing, etc…. There
are thousands of blog posts and hundreds of books that tactically address the
question “So… what do I do now?" for all of those categories.

But for those of us who continually ask ourselves “How do I create a successful SaaS
product?" there isn’t that much going on. Us Product Creators are left to figure that
part out on our own.
There is no simple checklist that, if followed, will ensure a successful product. But
there is no simple checklist that will ensure Customer Success or a good User
Experience either, and that doesn’t stop people from talking about best practices in
those categories.
This book is about best practices for a new category: Product Success.
Product Success as a Category

During the last decade as we have worked on dozens of products, we’ve learned
several things:
1. That creating a great product is incredibly hard.

2. That creating a great product is wonderfully rewarding.
3. That the core of a product needs to be meticulously refined over time.
4. That outside of a product, organizations like marketing, sales, and support
play critical roles in the continued success of a product.
5. And that most Product Creators have been missing something.
What we’ve been missing is the proper treatment of what happens at the edges of a
product. The Product Periphery.
Product Success happens in the places where you have an opportunity to interact
with your customers in important ways. These can be seemingly-boring things that
are easily ignored: your About Page, a Status Page, your email receipts. And they can
be eyebrow-raisingly odd: designing your product to be mobile first, using things
called LRQs and SRQs.
But those things--those Product Success best practices--can make the difference
between a good product, and perennially awesome product.

“So what do I do now?"

If you’re someone who has ever asked the question “How do I create a successful
SaaS product?" then keep reading. We guarantee at the very least it’ll give you
something to think about.

Creating Successful SaaS Products by Ramen.20160215

Diunggah oleh

Informasi Dokumen

Hak Cipta

Format Tersedia

Bagikan dokumen Ini

Bagikan atau Tanam Dokumen

Opsi Berbagi

Apakah menurut Anda dokumen ini bermanfaat?

Apakah konten ini tidak pantas?

Hak Cipta:

Format Tersedia

Creating Successful SaaS Products by Ramen.20160215

Diunggah oleh

Hak Cipta:

Format Tersedia

Creating Successful SaaS Products: An

Introduction to Product Success

Who Should Read This Book? ............................................................................................... 8

Part 1: Low Hanging Fruit ................................................................................................... 10

◦ About Pages ............................................................................................................. 27

◦ Long Running Questions (LRQs) ............................................................................ 56

Part 3: Architect for Success ............................................................................................... 67

◦ Mobile-first Design .................................................................................................. 68

Thank You ............................................................................................................................. 81

Shameless Plugs for our Products..................................................................................... 82

Appendix: The Original Product Success Blog Intro Post................................................ 84

2 Product Success: Creating Successful SaaS Products

What is Product Success?

Strategic Product Success

Product Success: Creating Successful SaaS Products 3

The SaaS Product Hierarchy of Needs

4 Product Success: Creating Successful SaaS Products

Function: Does the product do something valuable? Yes? Great. Done.

And lastly is the pinnacle: Product Nirvana.

Product Nirvana: This is a state that we purposefully leave undefined in recognition

Product Success: Creating Successful SaaS Products 5

Product Success is a new category

Second, we haven’t been able to conduct extensive case studies to empirically

6 Product Success: Creating Successful SaaS Products

What did you think of this introduction?

Product Success: Creating Successful SaaS Products 7

8 Product Success: Creating Successful SaaS Products

We’ll take praise or constructive criticism. It’s all good :)

Product Success: Creating Successful SaaS Products 9

10 Product Success: Creating Successful SaaS Products

Better Ways to Use 404 & 500 Error

Product Success: Creating Successful SaaS Products 11

nginx: Who’s a bad gateway?! You’re a bad gateway!

12 Product Success: Creating Successful SaaS Products

Rails: Much style. Many color.

We should spend way more time on our error

Product Success: Creating Successful SaaS Products 13

SaaS != Everything else

14 Product Success: Creating Successful SaaS Products

Error pages should be better

Product Fail Yeti says:

How error pages can be better

Product Success: Creating Successful SaaS Products 15

Early on in Ramen’s history, anytime someone hit an exception, I would

Error Page Toolbox

1. Clicked a link or button while using the app

16 Product Success: Creating Successful SaaS Products

Method 1: Google Forms

What about single page apps?

Product Success: Creating Successful SaaS Products 17

// Ask Ramen 500 question on AJAX error

1. Fewer people use SaaS products than visit content/e-commerce sites, so

18 Product Success: Creating Successful SaaS Products

All SaaS Products Should Send E-mail

Product Success: Creating Successful SaaS Products 19

1. We use this service at Ramen. I saw a charge on our monthly transaction

20 Product Success: Creating Successful SaaS Products

You want people to constantly evaluate the value of

Product Fail Yeti says:

You don’t want people to question your motives

I tend to be borderline-delusional in my optimism on most things, and that definitely

Product Success: Creating Successful SaaS Products 21

1) Say who it is coming from

2) Say what account it is for