Doneness is in the eye of the beholder

I've been working in Product for over 15 years (please do not do the math to guess my age). So, I've been working with engineers for a long time. Despite that, I always have to remind myself that the definition of doneness is not universal. More than once, I've had conversations with my engineering teams about things being done that go like this:

I tweeted about this recently, and there were a bunch of interesting replies and questions. Here are my three tips:

  1. If you use agile, creating doneness or acceptance criteria for every story is overkill. It is too much work and time for not enough value.
  2. Doneness goes both ways, engineering and product design. I don't mean waterfall, or 10 page requirements documents. I just mean that there should be enough wireframe/design, user value, and business proposition fleshed out for engineers to reasonably spec out a prototype.
  3. Doneness isn't a laundry list, but a thoughtful framework by which we can determine the actual tasks that need to be done and create shared expectations.

My own doneness list for our internal products looks something like this (simplified for general understanding):

  • a product outline that defines the value of this product (i.e. where it needs to exist), where it fits into our broader set of products, the core features that it should have, database reqs/schema
  • designs for new UI elements and some inspirations from other sources
  • update the database schema
  • build the api integration for the internal products
  • build the front-end changes to the internal products
  • build the api integration for the user-facing portals
  • build the front-end changes for the user-facing portals (web, mobile, etc.)
  • create the integration tests
  • user tested at least once by eng
  • release into dev, with a clear outline of what features were introduced in this release and which ones from the product outline have not been released

Then, post this list in a clearly defined place - Google Doc, slack channel, etc. so everyone can read and access it, especially new people on the team.

And in case it wasn't clear, product should be collaborating with engineering and design to create the doneness list. Doing this simple task together can help set the right expectations (and estimates!) and avoid surprises and frustrations when it comes to doneness. 

Are your product notifications interrupt-driven?

I once googled "what is the beeping noise in my house" as an act of sheer desperation. I'd spent hours trying to figure out what was making the noise after turning off every electronic thing I owned (and I own a lot of them!). Amazingly, I actually got the answer! It turns out that I had put my old smoke detector in the back of a closet and forgotten about it.

I was reminded of that again today, when both my dishwasher and dryer had been beeping for hours. Like my smoke detector, the sound is strident and impossible to ignore. However, unlike the dishwasher, the constant beeping is also completely unnecessary. Once it's beeped three times once, and maybe again an hour later, I really don't need to be constantly annoyed by the dishwasher letting me know that it's done. However, I do actually need to know that the smoke detector battery is dead.

Funnily enough, I was interrupted by the sounds as I was in the middle of working through our notification messaging, and thought it was a great lesson in the art of notification design. Broadly speaking, notifications fall into three categories:

  1. informative - informing a person about an event he/she should be aware of
  2. requestive - informing a person about an event that you want him/her to take action on
  3. active - informing a person about an event he/she needs to take action on

I should also note that I'm defining notifications as broader than just in-app push notifications. A notification is anything that informs the user of an event, whether email, text, sound in a browser window or something else. 

Here are some of the key things to consider for these different types of notifications:

Informative

  • e.g. a payment has been made successfully
  • be thoughtful about whether the user actually wants to know this information
  • the event should be something he/she cares about
  • when users don't need to take action, don't get in their face
  • define the headline (i.e. the minimum info they need to be aware of) v. the article (the additional data that is useful but is skimmable)
  • notify once, or maybe twice with the appropriate wait time in between notifications

Requestive

  • e.g. provide an app rating
  • what's important to you isn't necessarily important to your user
  • you're asking them to do you a favour
  • if you don't show that you're thoughtful about their time, you're more likely to lose their goodwill
  • as far as possible, allow the action to be taken within the notification, e.g. embedded form in an email
  • keep the request simple and easy, e.g. a 3 question survey instead of a 10 question survey
  • think about whether you can or should offer the user something in return for their work

Active

  • e.g. choose an account to make a payment
  • these often relate to payment, or something negative - how can you soften the blow?
  • copy is critical - show people you're respectful of their time, be factual and succinct
  • again, define headline v. article
  • include all the information they need to make the decision
  • provide confirmation that it's been done

So as you think about your product's notification strategy, consider the categories in which they fall, recognize that you're being interruptive and think about how to be respectful of your user's time.

 

The REAL friendly skies - 3 tips for customer service interactions

Customer service is all about when things go wrong. But it's so much more than lip service. It's not even just about solving the problem (obviously, that's step 1), but about how the customer feels when it's all over. If you're doing it right, customer service interactions don't happen very often. So when they do happen, they are major decision moments. Each customer service interaction is either a reason to love the company or a reason to never give the company another cent and worse, complain on social media.

This is even more critical for startups. Not only can we not afford to lose a customer, we definitely don't need the bad PR. I've been thinking a lot about what good customer service means for our business and how we can use it as yet another opportunity to engender loyalty.

Based on my experiences as a product manager and a consumer, there are three things that are critical to creating a great customer service experience.

1. Make good input easy and fast

Too often, customer service forms look like this:

Invariably, this means that I have to spend my time gathering information, and half the time, it's too much work to bother so I don't even do it. This may help your customer service metrics because there are fewer complaints to deal with but in the long run, you want to know when things went wrong and why.

Great customer service inputs make it easy for people to classify the problem, add pictures and videos, and identify if there are specific transactions that it relates to. And it might sound counterintuitive, but if you can create the right form, more clicks actually make it easier because each click represents one or more sentences that I no longer need to type in.

My favourite example of this is the Uber trip feedback/problem form. Now, when you have an issue (e.g. cancellation, poor driver, fare review), you can select the trip, add the details and submit. And the great thing about this is that because the information is provided in a structured format, the data can be automatically processed. If we can use data to respond to the request, no one has to touch it and most importantly, it gets solved even faster for the customer.

Create structured input that is easy for the customer and you can create a data-driven method for customer service that can eliminate the need for multiple touches and solve the problem faster.

2. Always respond in context

We use Intercom for our customer support. One of the great things about it is that when you respond, you can see the person's profile while you respond. Intercom collects a great set of default customer information, but what's more powerful is that we can integrate our own custom attributes and events into the profile.

This allows for great personalization, so responses feel unique and special. This is not to say that some customers should be treated better than others, but simply that a great personalize customer service interaction can make the relationship stronger.

I experienced this in real life recently while flying on Qantas. I'm vegetarian and for whatever reason, my vegetarian request hadn't been processed. The staff was phenomenal and went out of their way to create a vegetarian lunch for me and make sure I was happy. That itself went a long way. But what was even more phenomenal was that on my next Qantas flight to/from completely different locations a few days later, those staff members checked to make sure that I had my vegetarian meal, and gave me a bottle of wine and apologized for the issues I'd had on my last flight!

mind blown.

mind blown.

There's a big cost difference in Australian carriers. But even though it costs more, I'll pick Qantas every time. That level of personal consideration creates incredible loyalty. And I'll also note that my frequent flyer status is actually with American, so this experience with Qantas was even more remarkable.

So in all of your service interactions and follow up interactions, find the context and use it.

 

3. Make it easy to share

Finally, this is something that I don't see many people do. I often see NPS surveys or a way to provide internal feedback but not an easy way for me to post my great customer experience to Facebook or Twitter.

In a way, this is like app ratings. There are lots of great insights on how to get good ratings and not be obtrusive. Similarly, I think there must be good ways to share great customer service experiences that don't feel intrusive or pushy.

Sharing great moments is something that people are used to doing in all kinds of forms on social media. Having a simple approach to making that easy for them can result in virality and genuine social media love.

APIs are not enterprise solutions

This post is a follow up to my earlier post on how startups are built on other startups.

post 1 tldr; startups need to use the API platforms that other startups have created as building so that they can focus on their core value proposition. e.g. Uber wouldn't exist today if we'd had to build payments, messaging and maps from the ground up.

Properly, I should say startups are built on other companies, because many APIs are created by larger companies, such as Google and Twilio, which are publicly traded. Fortunately, many companies who own these APIs understand the value of supporting an ecosystem of smaller players that can then grow to become larger players.

Support for startups when it comes to APIs, for me, comes down to:

  1. easy signup
  2. fair pricing
  3. online documentation

Stripe is a great example of a company that does all of these things well. 

1. the call to sign up action is clear, and obvious. It requires basic information and you can create your account immediately to test it.

2. The pricing is transactional, and still reasonable at small volumes. 

3. The documentation is available online, and clearly organized.

 

Unfortunately, this is not the case for several APIs that we're trying to use, which happen to be specific to Australia. I think the primary issue here is that these companies aren't used to providing their APIs to startups, because their primary consumers are large enterprises such as Australia's big banks, which have people who can gather reams of documentation and can afford to pay monthly fees in the 4-5 digit range.

What is especially frustrating is that all of the data provided by the API is freely (or very cheaply) accessible through the company's own websites, and our usage of the API has no impact on the company's monetization strategy.

For many of the companies who provide APIs and their own portals to access the data, the default assumption is that if you want the API, you must be a large company. APIs are not enterprise only solutions, but looking at the pricing pages, that seems to be the default thinking. In fact, on these websites, there isn't even a pricing page option, but only a link to contact the enterprise sales rep.

Now, in no way am I suggesting that these companies should make APIs free. There is obviously a cost to developing and supporting reliable platforms. However, there are a few simple things that could be done, which can make a huge difference in supporting companies who want to create products and grow the technology sector:

  • Make signup simple - let people create sandbox accounts with a few clicks to test and play with the data. If you require verification and further details, let it come down the line when with access to production data.
  • Define pricing beyond enterprise solutions - create a low call limit and provide an option for startups who want to use the data. Create a pricing page, not a contact the sales rep page. Do some benchmarking to understand what other companies are doing in different parts of the world.
  • Put documentation online - Create websites, not PDFs please, and add a clearly titled link from the home page.

If you have an API, why limit your user base to only large enterprises? There are plenty of ways to make your APIs available to startups in ways that don't burden your API/Platforms team. And at the end of the day, if your API is instrumental to helping a startup grow, you've just gained yourself a big new customer.

Startups are built on other startups

A few years ago, I spoke at the Accel APX conference, and our core topic was about how startups are fundamentally using other startups as their building blocks to create a core value proposition.

For example, it would have been a lot harder to build Uber from "the ground up " without Braintree for payments, Twilio for SMS and messaging and Google Maps for well... maps. Every single one of those areas is a massive company on its own and if we'd had to create each of them from scratch, we'd still be working on it.

To me, that's one of the things that makes America a place where companies can focus on what makes them special from Day 1. At a simplistic level, it's a question of build or buy. And when it comes to core infrastructural things, it makes no sense to build that up from scratch as a startup. The question might become more complicated as a company scales. Being big can be expensive, but it can also lead to volume discounts. And when you ask yourself where your engineers, designers and product managers should be spending their time, it's rarely on the things that have already been built. As they say, if it ain't broke, don't fix it.

Having come from that kind of environment, I've found it challenging to accomplish some of the same things in building out our company in Australia. There are some fabulous companies who have strong global products (thank you Intercom and Twilio!), but there are a number of platforms where the API solutions are incredibly expensive, or require onerous applications or don't even exist. As a result, I think it stunts the ability of Australian startups to actually deliver on their promise.

I think there are two fundamental issues here:

  1. lack of companies building platforms that support Australian needs
  2. companies treating APIs as only "enterprise" solutions

On 1, there's a sense that Australia is a small market, which is why it doesn't seem to factor as highly in global expansion. I don't think that this is a well-informed or complete point of view. I'll point you to my co-founder's post on this for more details, but will leave you with one stat.

“In 2015, Australian GDP was over USD$1.3T, yet total venture capital investment was ~$300M. India, with GDP of USD$2.0T did 12x that investment in the third quarter.”

But either way, if global companies aren't in a position to build this out now, there's an opportunity for Australian companies to do better. For example, our company requires a mobile payments API solution with direct debit, which is a primary method of payment in Australia. I feel like people are completely used to giving out their bank account numbers and BSBs (routing numbers if you're in America) without batting an eyelid.

I've only found two companies that have this kind of API, but was rejected outright by one of the companies because I didn't want to provide them with:

  • A 20 page business plan
  • Detailed screenshots
  • All our requirements documentation
  • A Sydney office address

Fortunately, I had an alternative, which is slightly more expensive but open to working with startups, and has public API documentation. If this company didn't exist, our company wouldn't.

I'll save my comments on point 2 for the next post. Fundamentally, I think this layer of companies that provide the building blocks for startups is a critical component to creating a thriving startup ecosystem.