As Jared Spool notes, when teams are designing and building for themselves, they consistently improve the tasks that they do frequently but ignore the critical-but-not-frequent tasks.

The most common of these neglected tasks is a new user signing up and getting onboard. Everyone does this once and once only, so dogfooding doesn’t highlight any opportunities to improve it. But ignoring your onboarding is equivalent to redecorating a restaurant dining room while simultaneously ignoring the dead body on the doorstep. You might wonder why there’s no guests, but no one else does.

Here are some signs that you’re dogfooding too much.

1. An out-of-date product tour

At one point in your product roadmap, someone went ahead and designed a product tour to showcase all the features you had. It probably worked wonders for any newly acquired customers around that time.

Then the UI changed. More features were added, some features were killed (hopefully), and updating the product tour became a chore. One that got ignored in favour of new features and more shine.

Now new customers arrive and can’t make sense of anything. Something that was in preferences is now in settings. Some screens are gone. Some look totally different. New customer don’t see this product tour as being ‘out of date’, they see it as confusing as hell. Rather than engage customer service, they’ll flick back to Hacker News and think about how it’s been a while since they found a good product. Potential customer lost.

2. Documentation & Screencasts no longer relevant

Along with ignoring the onboarding experience, your product team don’t regularly read documentation or watch screencasts. Why would they? They know exactly how it all works, they built the damn thing.

So no one realises that the docs are hopelessly out-of-date. No one notices that the screencast carries the wrong logo, and explains how to do things in an old version of the UI that is no longer available.

To new customers, these docs are even less helpful than the product tour. The screencast is great but they can’t find the screens that it shows, no matter how many tabs they click on. They’re confused. We know what confused customers do. They click “Back”. Potential Customer Lost.

3. Poor onboarding communications

Life cycle mails, drip feed marketing, marketing automation—call them what you will, they too go stale as a product matures. This can get very messy: call-to-actions in your emails can 404, special discounts can no longer apply, screenshots and how-tos expire… there’s a lot of content that needs to be kept fresh here, but the product team doesn’t don’t receive “Day 3 engagement mails”. They’re on day 300. So who notices when all these communications go out of date? Customers do, and again, rather than report it, they just click unsubscribe. Potential Customer Lost.

Sign up for your product every week

The only way you’ll notice any of these problems is by making “onboarding” something you evaluate regularly. Then you’ll catch things before they get out of hand and you’ll update them. This is hard work, but so is creating good software.

These extra tasks are why start-ups look back with a sense of nostalgia at the days when they could bash out new features every week. There were no docs, no screencasts, no product guides, and no life cycle emails. Sure, the product was smaller, but more importantly there was no product collateral to be maintained. No customers to be communicated with or upsold. It was just “put this live and see if it works”. Now it’s “document it, update the product tour, edit the screencast, re-write the welcome mail, and then put it live”. I know you’re thinking: software is much easier when you don’t have customers to worry about.

To start-ups who tell me that they dogfood their product all the time, I say that’s great. But remember, to actually eat dogfood you have to open a brand new packet, every single day.

What follows is a guest post from Paul Biggar, founder of popular developer tool CircleCI, detailing how Intercom impacted their bottom line, by retaining customers who were ready to quit.

CircleCI provides Continuous Delivery for software development teams. This means that each time our customers push code to GitHub, we run all of their tests, and might deploy their applications to production.

Since we’re a key part of our customers’ developer flow, one of our core values is great support. One of CircleCI’s first UI features was a “help” button; we had to nag Intercom (then in private beta) to get access to it.

Our other core value is that we support whatever our customers can throw at us. While services like Heroku demand you conform to best practices, we recognized that part of our job is to support customers’ existing applications, even if they’re doing weird things that are way off the beaten path. This core value created an unusual problem.

What was the problem?

Customers expected that if their tests passed on their machines, that they would always pass on CircleCI. In practice, tests fail for a huge variety of reasons, everything from differences between OSX and Linux, to not being tested correctly on a developers’ local machine.

We automatically set things up so that their tests can run in one click, so when their tests failed, it must be our fault, right? The problem is that potential customers rarely become customers if their tests don’t work. So we were losing customers because they didn’t know why their tests were failing.

How could we talk to these customers? How could we ensure that they talked to us instead of giving up? How could we learn their pain points and fix them, and turn a failed test suite into a positive customer experience?

Intercom to the rescue

We reach out to customers all the time. But we wanted to make it really easy for customers to reach out to us and start a dialog about their problems with us. There are too many products out there that have a “fire and forget” policy to customer service, and that’s not the experience we want for our customers.

Our solution was to add a lot of encouragement to contact us. We added big red attention-seeking button that said “Report…”, and an error message highlighting that you could reach out to us right now. And naturally, we hooked them both up to intercom.

Now we receive a time-sensitive and context-sensitive report about our customers’ issues, and when we reply, customers see our smiling faces next to the solution to their problems.

Implementation

We wired the buttons straight into intercom. Here’s what it looks like. When you click “Report…” or “report this issue”, it brings up the Intercom dialog prefilled with the important information:

This probably looks familiar. It’s the usual Intercom message box, prefilled with “I think I found a bug in Circle at $your-current-url”.

Let’s look at the original CoffeScript:

So it’s pretty straightforward. Just use Intercom’s jQuery to step through the same actions as a user clicking.

Better customer experience

We have the philosophy that everything that a user reports is a bug: if they’re not able to successfully use the product, it’s a problem in the product. By giving customers the ability to talk to us at the exact moment when they have a problem, we’ve learned about hundreds of bugs, from places where we could be communicating better, to problems in our platform.

As well as learning, we now have an extra opportunity to provide a wonderful experience, especially to new users. This has turned hundred of prospects into customers, customers into CircleCI evangelists, allowed us to fix lots of problems with copy and marketing, and turned bad experiences into great ones.

Give Circle a Try

If you’re looking to increase your dev team’s productivity through Continuous Integration and Continuous Delivery, you should check out CircleCI. The Intercom team has been using it for a year, and everybody loves it! If you start a trial today using this link, Circle will give you 50% off the first 3 months.

Why did this work?

Paul’s post is a good example of identifying moments where customers are stuck and using messaging and good support to un-stick them. By being pro-active, making it clear you’re available, and defaulting to smart messages Circle maximise their chances of keeping a customer in the loop. It’s also a good reminder that every single piece of friction during on-boarding costs badly, and this problem only gets worse with scale.

So to improve your onboard, identify these moments, investigate them, and eliminate them while you can. Often it’s just a case of starting a conversation.

This is rarely true. In fact, more often than not, it’s the other way around. 47% of first-movers fail, compared with only 8% of fast followers. As the phrase goes, you can recognise a pioneer from the arrows in his back.

First-mover advantage isn’t automatically bestowed unto the first product in a category. It’s not even guaranteed to exist in your industry and, when it does, it is fought for and earned.

It’s First Winner, Not First-Mover

As Alan Cooper notes, being first to the market means precisely nothing. Being the first to enter a market brings opportunities which, when exploited, turn into advantages. First-mover advantages have a shelf-life and must be replaced with long-term differentiators.

There’s three types of first-mover advantage you can achieve:

1. Maintain a Technological Headstart

If you invent the category-defining technology, you have a potential head start when it comes to expert knowledge, usage data and customer feedback. Exploiting this advantage means playing your cards very close to your chest. You can’t release early prototypes, you can’t explain how anything works, or even let customer feedback be publicly accessible. All of this gives would be competitors a head start that you never had. This is what baffles me about Glass.

Google have chosen to throw away any possible advantage. The product is already out there in an embryonic phase. Not ‘live’. Not launched. Not secret and in-development. It’s out there for anyone to use and for Scoble to shower with. If there are any good use cases, you can bet that competitors have found them and are busy working out better ways to do it.

When your breakthrough product is launched your competitors will disassemble and reverse-engineer it. They’ll interview your customers and find out the true value of your product, the job it does best, and they’ll take all this data and start building the next generation of your product.

A year later they will all ship their 1.0. They will catch up to where you were. If you’re still standing there, you’re toast. This is when you need to be shipping your 2.0, leaving them in the dust, relegating them to be the company who always delivers “Yesterdays Technology Tomorrow”.

That’s first-mover advantage.

2. Make Defensive Moves

Along with out-innovating your competitors, you can protect yourself with a selection of defensive moves. These are any tactics that prevent your opponents following in your exact footsteps.

Such tactics include things like:

• Exclusive partnerships with core component suppliers, e.g. pay a supplier over the odds to ensure that no one else can use their technology in your industry.
• Killing primary distribution channels, e.g. block booking advertising with your best performing networks or platforms.
• Winning patents to prevent your technology being directly copied and used in your industry, if not industry wide.

3. Lock Up The Early Adopters

By signing up early adopters (i.e. those quickest to adopt or most influential in your space) you can make it near impossible for new entrants to get any foothold. This is most effective in the formative stages of a product category, and is achieved in two ways:

• Bribery: Simply give away free devices or accounts to the noteworthy people, and let them spread the word.
• Long-term contracts: If you’re confident your product is sufficiently desirable, remove mobility of customers with a nice 12/18 month contract.

How Valuable Is First-Mover Advantage?

In the HBR paper The Half-Truth of First-mover Advantage, Fernando Suarez and Gianvito Lanzolla argue that the value of being the first-mover depends on two key factors.

Factor 1: The Pace of Innovation

The speed of improvement varies from category to category. Look at how email sat stagnant for 8 years following Gmail, in comparison with how quickly many social networks were born, bought, acquired and killed in the same period.

The speed of improvement also varies from era to era. For over a decade there was no worthwhile innovations in payments technologies, either as a business or consumer. But now in 2013 there’s innovation everywhere thanks to Stripe and Square unlocking the market.

In short, the pace of innovation is a measure of how much better the leading software is on a year to year basis.

Factor 2: The Pace of Market Adoption

The speed of adoption varies from category to category, depending on their necessity, cost, ROI, and other factors. Some categories are instant hits, with 100% penetration within a decade, others can take 20 years before hitting double digits.

Combining these two factors gives us 4 outcomes.

Stable Market, Stable Product

This is where first-mover advantages have most to offer in the long-term. If you grow your product at the same pace as the market grows, you effectively define the category, making it hard for new entrants to play your game. This is why people ask for Biros, Scotch tape, hoovers, blu-tac and other category defining products.

Market Ahead of Product

In theory this is a nice place to be. Customers are rapidly consuming your product in increasing amounts without any significant innovations from you. The challenge here is to get it into the hands of every potential customer.

This is why it’s important to expand your addressable marketing, usually through multiple price points, multiple countries, multiple devices, etc. Failure to do this means you will be a local leader (e.g. the best daily deals site in North America, the best instant messenger app on Android, etc), which allows rivals to gain footholds elsewhere. Effectively you open the door to the Samwer Brothers.

When the market leads the product, there is a strong chance that first-mover advantage will be beneficial in both the short-term and the long-term, provided you address all potential customers.

Product Ahead of Market

When the technology is changing rapidly, and the market is slow to adapt to the product, being first is effectively useless.

Every new technological advancement brings a new wave of competitors, and customers don’t care who produced the first, now laughably obsolete, product. Customers simply want the best available.

The tactic here is to refine the user experience of the product such that it appeals to more than just early adopters. This is what Apple did when they watched Saehan, Diamond Rio, HanGo, Creative Nomad, Cowon, and Archos all launch increasingly more advanced MP3 players to a slow-to-adopt public. Rather than getting caught in this mess, Apple waited until the technology was sufficiently advanced, and the market was sufficiently matured, before launching a product with the best experience.

Market & Product both Volatile.

This is a dogfight. The technology is improving quickly while demand for the product increases rapidly.

A new entrant gets a short-term advantange here, as their slight improvement will gain a small foothold in the expanding market. WhatsApp, Viber, SnapChat, Line and others have all been #1 at some point only to be displaced. This is where the “building to flip” strategy can make sense, and also where investors need to distinguish short-term advantages from long-term strategies.

The following diagram sums it up, and should help you decide whether to rush to market, or take your time and get it right. Thanks for reading!

What follows is a guest post from Nathan Kontny, founder of Draft, about how Intercom gave a serious boost to his Monthly Recurring Revenue.

To sustain Draft I needed to make more money. Draft, if you haven’t heard of it, is an online text editor with version control and collaboration tools. I created it so people could improve their writing.

Draft has two revenue sources. There is a professional editing service inside Draft, and also a paid subscription. You can use a full featured Draft for free, but if you want to support it and keep out annoying adverts, then you can upgrade to a paid plan.

I set a 30 day revenue target that seemed simultaneously humble yet ambitious, given it was a new project. I hoped that paid subscriptions would help me hit that target. Things started out great: the very second I turned on the “Please Support Draft” button, someone upgraded. Yay! Next I sent an email out listing all the new recent features and that paid subscriptions were now available, and I got a nice bump in revenue. Midway through the month upgrades slowed down dramatically. I was in danger of missing my goal by some distance.

How can I …

One thing I’ve learned over and over is to never get wrapped up in “I can’t“. Instead, I force myself to ask, “How can I accomplish this?” Even if it takes me days or weeks, living and sleeping and working and reading and eating with that question in mind, good solutions eventually come to me. In this case it came to me via my text editor, Sublime Text.

I can use the full version of Sublime Text for free, but it gently reminds me with a popup window every so often to register my copy. I can’t believe how many times I’ve been forced to pay to register for a product’s premium features only to be sorely disappointed, and now I have to figure out how to get refunded.

What’s interesting about Sublime’s model is that it’s rarely used online. Sure, there’s projects that have fremium versions and they might even stick an ad in the sidebar to remind you to upgrade. But I don’t see anyone using a reminder message like Sublime does.

However, even with this insight I postponed doing anything, because I had way too many other things on my todo list and this seemed like a bit of work to set up.

Enter Intercom

Intercom is a tool I use to do customer communications and messaging. In a nutshell, Intercom makes it easy for users to message me and me to message them, either using email or in-app popups. It also allows me to easily segment customers, so I can see who is using what features and how often.

As I asked, “How can I possibly reach my revenue goal in time?” it dawned on me that I could use Intercom to accomplish this reminder window with very little work. In two minutes I can get data like this into Intercom:

I only want to remind people who are actively using Draft with this message, so I can filter down to the right people with the following filter. (Note screenshot edited)

Which created this rule

This was the in-app popup I sent:

And heres the Markdown behind it:

One other thing you might notice in this reminder window is it’s an Intercom conversation, so it’s a two way dialogue. This way I was able to include a question “If there’s a reason you won’t subscribe, I’d love to hear your feedback. You can reply to this message below.“

I got this idea from Noah Kagan, the founder of AppSumo and blogger at OkDork. One of three things is going to happen:

1. Your potential customer will realize they don’t actually have an objection to buying today.
2. You’ll hear real objections which you can test and solve immediately and potentially win a new customer.
3. You’ll learn what features paying customers value so you know where to focus development.

What was the result?

I had a 200% increase in subscriptions the day I turned this popup on. I ended up meeting my goal 9 days early! And the increased rate has held steady.

I’ve had lots of friends ask about Intercom, and I keep telling them it feels like a Swiss Army knife. There’s lots useful ways you can use this messaging tool with the data it captures. For example, every few weeks I send a “New Release” email that generates a lot of activity. And I’ll use more in-app messages to indicate new features as I deploy them. I’m just scratching the surface of Intercom.

It’s also another reminder that asking How, instead of moaning I can’t, led to a great solution. You often end up realizing you have the resources already under your feet.

Why did this work?

I would tentatively attribute Nathan’s success to 3 components:

1. Nathan’s initial email contained more than one update, which means the upgrade tone was fighting for attention alongside more interesting feature announcements. A common rule in marketing is Never try to sell two things at the same time. Important announcements are best done standalone so they can dominate the body & subject line of a mail.
2. An email asking for an upgrade is likely to arrive out of time, out of context, when the product isn’t in use. Sublime Text show the pop-up when you try to use the product. Not the following evening when you’re archiving emails waiting for a train. Nathan’s in-app message was shown to the right users at the right time.
3. Not all customers will be ready to buy the second your email drops. Nathan’s post is a great reminder that “Customers buy when they’re ready to buy, not when you’re ready to sell”. Some customers need a few reminders before they upgrade, some still need persuasion. This is why message schedules are useful.

Got a great use case?

If you’ve achieved success with an Intercom message and would like to share it on our blog, drop a mail to des@intercom.io and we’ll get talking.

You’ll find lots about his background elsewhere, but in summary: He helped design Dyson vacuums. He helped design Gmail, YouTube, Google+ and so many other Google properties—his name is on the patents behind the Circles concepts. At Facebook, he has helped their very biggest customers, like Nike and Procter & Gamble, design experiences to help them connect with their customers on the Facebook platform. He is the author of a very famous presentation that foretold much of the social innovations we’re only seeing come to fruition today, and of bestseller Grouped. From my perspective, he’s the leading name in Social Design, a still-emerging field that is fundamentally relevant to the Intercom challenge. Because ultimately our job is helping our customers connect with theirs.

When Des and I first met Paul about 5 years ago in San Francisco, we knew we wanted to work with him. Hiring him was a laughable idea back then when we were running our tiny consulting firm Contrast—but I still suggested to Des that we might try. (I never actually had the balls to.) Paul has been a hero of both of ours for many, many years. Some people make you comfortable enough to openly dream about the future and will share and then expand upon those dreams. Others are smart enough to synthesize those ideas and execute on them to turn them into reality. Paul is both of these people in one.

I’ve always felt that the best way to build a great team, is to build a great team. Great people want to work with great people. You can pay over the odds, motivate people around an ambitious mission, and give them interesting problems to solve. But in the technology industry, there are many companies offering these things. However, your people will always be unique. Not copyable. Proprietary, if you will. Personal relationships bind teams together through thick and thin. They are something real to invest in that everyone has an inherent sense will be valued until the day they die—and certainly much longer than the timeframe our industry usually operates in where companies are founded, funded, folded or acquired in a blink of an eye.

Making your great team greater requires you pull in some truly special individuals from time to time. And sometimes that takes 5 years. As Head of Product Design, Paul’s job will be to build one of the greatest software design teams in the world, and with them to bring the Intercom dream to reality. Welcome, Paul!

You can read more about the news on Techcrunch, CNet, Business Insider, GigaOm, and AllFacebook.

The common mistakes are:

1. Believing everyone should be happy to pay for your product.
2. Believing there is some mythical “perfect” price which extracts maximum revenue from every single customer.
3. Believing product pricing can never be changed once chosen.
4. Delaying charging indefinitely as a result of 1, 2 and 3.

The vicious cycle is that the longer you wait before charging, the scarier the challenge gets.

Joel Spolsky explains why there’s no good “right” price in his seminal article Camels and Rubber Duckies, and Jason Fried’s strong concise advice of put a price on it, and see what happens cuts through a lot of the meandering and explains that though you’ll never find the right answer, you should start with something that isn’t $0 and you’ll learn plenty. This is a great approach to get pricing initiated.

Dozens of entrepreneurs have weighed in on pricing, and there seem to be a few common lessons that all have learned in hindsight. None of these can answer the “what to charge” question but they will give you guidance.

1. Charge earlier than you’re comfortable with

This is especially useful in the early days of product development, when you’re guided by customer feedback. Customers who don’t pay for software, or who want big discount codes on a $9 per month plan, are the wrong ones to take feedback from. As a rule of thumb, feedback from non-paying users tends to focus on additions to the product. Feedback from paying customers focuses on improvements to the product.

Customers who “will buy it when it…” are like the pot of gold at the end of every rainbow. They look super valuable, but they’re always one feature further away than you had thought.

2. Charge more than you’re comfortable with

A four person company is a ‘small’ company by anyone’s standards. Typically this puts them on most products “small”, or sometimes free plan. But their monthly outgoings are going to be at least $16K. This puts $19 per month plan in perspective. I know startups charging engineering teams in IBM $19 per month for software that is embedded in the workflow of dozens of their employees.

If your software is critical in a company’s processes and you charge less than their morning coffee run, something has gone wrong.

3. Justify (or kill) your lowest plan

A lot of web applications include a bottom-of-market plan at $5 or $9 per month. This price plan is included to back-up the “affordable for everyone” claim that sounds so nice to say.

Costs like hosting, salaries, etc. are spread across all customers, but some costs are fixed per customer, such as Cost Per Acquisition (CPA) and Cost To Serve (CTS). Customers on your $9 plan cost just as much to acquire and are often just as expensive to serve as customers on your $49 plan. Adii Pienaar of WooThemes solved this problem by refusing to support non-paying customers. If they’re not willing to pay you, then they’re not your customers.

It’s generally accepted that you can’t grow a software business charging only $5 per month, so the chief argument in favour of the bottom tier is always that “these guys will move up through the plans”. In practice, that’s not likely when the bottom tier is super cheap. There’s two problems here: churners and low earners.

Churners and Low Earners

The bottom tier of any pricing grid experiences the highest churn. Intuitively this makes sense; small early stage businesses are more likely to fail than larger established ones. This means that most of the businesses you’re subsidising at the low end are going to disappear. In many cases you won’t ever recover your CPA, let alone ever make any money.

These customers are also the least likely to upgrade. Tiny companies do occasionally grow into large customers, but more often than that, they stay where they are as small customer paying you $9 per month. You’re not in the business of investing in the future potential of businesses. You’re in the business of making money today. Lots of companies have killed off their bottom price plan after this realization only to see support costs go down, and revenue go up. Win win.

In short, never include a price plan that you couldn’t run your business off.

Note, this is different to offering a free plan. A free plan is designed to create limits that will be crossed by active users. Typically these limits based on capacity (e.g. store up to 2GB) or specific features. Sometimes free plans are restricted to certain types of customer, e.g. non-profit, open-source, etc. This is a purely marketing exercise, to gain word of mouth, and should be measured as such.

4. Plan on changing prices

As you improve your product by adding features, speeding it up, improving the UI, or through various other means, it’s worth asking yourself some questions. “Are we delivering more value than we were 2 years ago?”, “Are our new customers less price-sensitive than previous ones?”, “Has our marketing improved?”. If the answers are consistently yes, it’s worth revisiting your pricing. In this regard you should always document the state of a product when you alter prices, as it makes comparisons easier (e.g. “People were already signing up for $49 last July before we had a calendar or any time tracking features”).

The fear of changing your prices often is actually the fear of complaints. Grandfathering avoids a lot of this, as current customers are unaffected for a period of time, and new customers will know no different.

The power of good pricing

Nothing impacts your bottom line better than improving your pricing. Two independent studies by McKinsey & A.T. Kearney , both concluded that a 1% increase in pricing affects a company’s profits more than any other change. In short, of all the things you can spend time tweaking, pricing will yield the best return. For some reason deploying your product and never changing it seems ludicrous, yet deploying your pricing and never changing it doesn’t.

No silver bullet

There’s no magic formula for pricing in Excel. The main thing to get right is to divide your pricing along some axes of value received. Make sure new customers can afford to get on board, but also that customers who extract the most value pay the most money (e.g. big teams, big companies, big dependencies etc.). If you get that right, then you’re half way there, and that’s as close as most people get.

Shipping unlocks a feedback loop that confirms or challenges those assumptions. It makes new things possible for your customers, and gives you the opportunity to focus on the next thing.

Shipping brings life to your team, to your product, and to your customers. Shipping is your company’s heartbeat.

Shipping will try to kill you

The scramble to get that one last feature done, the late nights, the compromises, the sinking feeling when we realise something major is broken, the post-mortems… It’s agony, but if it was easy everyone would do it. Shipping exposes mistakes. We’re nervous about it, and our natural reaction is to do it reluctantly and infrequently, which actually carries higher risk, causing more reluctance in the future.

The cost of shipping is approaching zero

Not too long ago, shipping software involved actual ships, disks, and printed manuals. It happened perhaps once a year. Bug fixes weren’t automatic over the internet like today. Everything was slower and more controlled. The cost of shipping was massive, the consequence of a mistake was large. Today, the cost of shipping has approached zero. Most people can deploy in seconds or minutes with a single command or button click. With a little thought you can do that without your customers noticing, and with automated monitoring you’ll find out immediately if something goes wrong.

Despite the cost of shipping approaching zero, many people still ship software guided by very old habits.

Shipping cadence defines your company

The cadence at which you ship defines your company. A yearly cadence results in a very structured approach to the design->build->test cycle. A few months of building, while the rest is spend fixing. Engineers can join and leave before seeing their hard work end up in the hands of customers. The approach to design becomes one of anticipating all possible needs, rather than focusing and iterating on the important ones.

Obstacles downstream propagate upstream

An obstacle downstream propagates upstream. If you’re not allowed to implement new ideas, you stop having them.
- Paul Graham

The right approach to shipping has a positive influence on your company’s productivity and your team’s happiness & job satisfaction. Shipping infrequently is an obstacle. Ship slow, and you’ll introduce challenges that push you to ship even slower. Ship frequently, and see positive effects everywhere in your company. For example, lets examine how behaviour changes along with shipping frequency, while handling a simple request from a customer.

Lets say a customer gets in touch to say “No matter what I do, I cannot save my name correctly, I think it doesn’t like hyphens“. In a company where you ship continuously, you see this and think Simple — I’ll tweak a test and a regex pattern, get a quick code review from my buddy beside me, merge to mainline, and 1 minute later when it’s deployed to production, reply to the customer: “Sorry about this, it’s fixed now, thanks for letting us know“. They’ll reply: “Wow, thanks for fixing so quickly“. High fives all around!

If we stretch the time to production (TTP) out a little, even to 10 minutes, the behaviour changes. You either do the same, but reply saying it’ll be fixed with our next deploy (probably 10 minutes) – or you wait, so that you can communicate with certainty. The waiting is time where you’ll shift focus to something else, but have the baggage of having to follow up. Perhaps you’ll think, I’ll have a quick coffee, then move on to something else afterwards. Even though your deployments are entirely automated, you lose time because of waiting and losing focus.

If TTP is hours, the behaviour changes again. No longer can you say with certainty when the change will be out there, so you’re tempted to batch up with other similar small changes. You postpone replying until you get time to do it, sometimes forgetting about it. You’re less likely to take prompt action, wow’ing the customer, and you pay some mental cost for having it on a todo list. Since getting to production takes hours now, your team will start restricting to morning only deploys, so miss that slot and it’s further delays.

If TTP is days, it exacerbates that further – perhaps you’ll reply “Thanks for letting us know. We’ll fix this in our next sprint”. It gets bundled in with a whole load of other small low, priority items, you spend more time debating estimates, and priorities, than the first guy took to fix it and reply to the customer. Miss the beginning of week deploy window and further slippage. The larger releases bring higher risk, you’ll tell your customer it’s fixed, only to later require rolling back because of a separate change. Your bug database gets bigger and bigger, with little details that you’ll probably never fix.

When TTP is weeks, it exaggerates that even further – perhaps you’ll reply “Sorry about this, I’ll let the development team know” or something equally lame from your customer’s standpoint. Deep down you realise nothing will be fixed, and the job of talking to customers becomes a cost or hassle, rather than an opportunity to improve your product and nurture happy loyal customers.

Shipping continuously

Better approaches to writing or testing software help us iterate more quickly and confidently, but the benefits are quite local to engineering teams. Continuous shipping on the other hand, touches all parts of your company, as do the benefits, and the behaviours it enables and encourages.

Linkedin’s transition to continuous deployment is linked to their recent financial success.

Good products, are a side effect of combining good people with an idea in an environment that helps those people to kick ass. Your attitude to shipping is a big part of that environment you create.

Shipping breathes life into how we think. The feedback loop helps us learn, gain confidence in making quick decisions, and build momentum. Momentum in product improvements excites and engages our customers. Seeing quickly the benefits of our hard work, motivates us to do more. Building a team where people can work hard and move fast attracts others to join you – hiring gets easier.

Shipping continuously isn’t an achievement you unlock and then move on. You’ve got to constantly obsess about it. If you believe in the benefits it brings, you’ll be driven to shrink 20 minutes down to 1 minute or less, you’ll consider ‘ability to ship‘ as an equal to ‘does it scale‘ when building new systems. And you’ll do that because of all the life it breathes into your company and your product.

Shipping is your company’s heartbeat.

As always, an MP3 recording of the conversation is available (40 minutes, 50MB), and there is an edited transcript below, with additional graphics to illustrate some ideas.

Des: Hi there, and welcome to Inside Intercom. Today’s guest is Garrett Dimon, the author of Starting + Sustaining, a practical guide for building and maintaining your own web businesses, and the founder of Sifter, a very popular issue tracker. Hi, Garrett.

Garrett: How’s it going?

Des: Great, thanks. I’d like to start this off by going back a bit. Five years ago you decided to quit your job, cut your salary to near nothing, move into a 500 square foot apartment, and start building Sifter, something you’d been sketching our for eight years previous. I want to know why.

Garrett: I have always had a fascination with issue tracking. When I got out of college, I went to work at Sapient and basically got thrown into very large projects that had to have a formal issue tracking process. So from the moment I was out of college, I was kind of tossed into that world and became very, very knowledgeable about bug and issue tracking.

And then after leaving—well getting laid off as the dot-com bubble burst—that experience stuck with me. And at my next couple of jobs the bug tracking was non-existent. At one point, I was working for a company who had outsourced development. I asked “Where do I report bugs?” And they emailed me a PDF and they said “Here, print this out and fax it to us.”

That was the point where I realised that not every company in the world has a great bug tracking process. I just kind of became curious and fascinated by that. I then spent pretty much my entire career doing consulting work for small to mid-size projects where the teams were never larger than 25 people. Big enough to need a formal process, but not big enough to need tools like FogBugz or JIRA. At the time, there wasn’t much else out there. You either took everything and used one of those apps, or took nothing.

Our clients wouldn’t use those apps. They’re not deeply technical people. They were intimidated by them. So we’d have a formal issue tracking process and it’d be all set up and we planned it out, and the clients would log in, and then within the next day, they would just email developers. And so that whole process basically fell apart simply because they wouldn’t use the tools we were using.

All of that experience over the years added up, and haunted me in the back of my head. I would always sketch and play around and explore. In hindsight it was inevitable that I would launch a bug tracker.

Des: Lots of what makes Sifter a great product is its fantastic design. You have some great screenshots of iterations online from showing hundreds of iterations over the header. Aside from the interface, how much of Sifter is about enforcing or suggesting a process to people?

Garrett: You know, I wouldn’t say it’s suggesting a process because it’s still fairly flexible. It’s very rigid in terms of options, but it’s flexible in terms of how the existing options can be used. There’s a karaoke bar in Portland that uses Sifter to manage tasks between bartenders and management. So the flexibility is there. Our goal is: let’s build something for the people who don’t need the complexity of the larger bug trackers. Build a tool so they don’t have to worry about configuration. By minimizing all that and putting constraints in place, it simplifies the burden on them to figure out how to use it and how to best apply it. It just makes it easy enough for them to hop in and start using it without feeling overwhelmed or turned off by all the options.

Des: One of the pieces of Sifter that is reasonably opinionated is that you don’t allow tickets to be on hold. Is that correct?

Garrett: Yeah, absolutely. That’s kind of the digital equivalent of sweeping it under the rug. You know, it sounds good. But once you start using it it’s just “I’m not going to take this issue seriously, so let’s just toss it over here and maybe that’ll we’ll come back to it later.” My view is fish or cut bait. If you’re not going to do anything about it, close the issue. If you’re going to do something about it later, you can reopen it.

If you get into too granular of a status, you end up with states that aren’t really states. They’re more kind of just various bits of information about the issue. A lot of times, people want specific resolutions. When an issue is resolved, they don’t want to put ‘resolved’, they want to put ‘won’t fix’ or ‘duplicate’ or whatever. And really, that’s not a state so much as a resolution. And resolutions are best captured in text where you explain why you made the decision you made so that for historical purposes you can circle back later and see. Saying ‘won’t fix’ as a state is a cop-out because it lets you not explain why you won’t fix it. And then a month later down the road, you come back and see ‘won’t fix’, but why did we decide we wouldn’t fix this?

Des: When I’ve used issue trackers that allow ambiguous states like ‘on hold’ tickets tend to pile up in whatever the most vague non-committed status is. In the end you can’t see the wood through the trees, because when you log in there’s like 800 issues, 5 of which are actually pressing, relevant issues, 795 of which are aspirational, “We’re going to do this someday”” type things.

Garrett: We do the same thing with milestones. The only way milestones are considered closed is once the due date is passed and all of the issues within it are closed. Often people are like “How do I close a milestone?” and I’m like, “Well, finish all of the work you put in there.”

If people could just close a milestone, they’d sweep all of that unfinished work under the rug. You have to make sure that you don’t just make it easy for things to just kind of accumulate without any kind of outcome.

Des: Have you ever tried any tactics to increase adoption of Sifter with teams? Do you remind people to come back and check it, or send out reports on how it’s been working for a team?

Garrett: I’m in the mind that if we’re not giving people something valuable in an email, that I don’t want to send people emails. I’m starting to get to the point where I can see we need to do more to educate people and help people use Sifter better before we start just making it more complicated.

On Traction, from 50 to 15,000

Des: Do you remember your first customer?

Garrett: I remember lots of first customers. It depends on if you count friends or not.

Des: The first customer you didn’t know.

Garrett: I don’t even know if I could say there was a first customer, because…

Des: You probably had 50 customers on the first day?

Garrett: Yeah. Like, the first day, we had a handful that signed up.

Des: And how did you get them?

Garrett: Really just through blogging, and, I guess the waiting list helped. I had an email list, and it was about 1,000 people and we sent out a, you know, hey, we’re live, email to those people. But most of it I think just came from blogging and from people who were interested in Sifter because by talking about it long before it was ready, it kind of pre-selected a certain audience that was at least vaguely interested in some of, you know, the thought process, and at least were fascinated by some of the same sick and twisted bug tracking stuff that I’m fascinated by. So I think that helped a lot.

Des: And where is it up to today? Do you have any numbers that are public around how many customers you have?

Garrett: Over any 30-day period, we have somewhere between 12,000 to 15,000 active users.

Des: How does that grow?

Garrett: Very, very linearly, and really through word of mouth. We’ve done a fair amount of advertising, but when it comes down to it, the best way we’ve grown really I feel is from things like Twitter and word of mouth. Just people signing up for it that have either used it at previous jobs or know people who have used it and recommended it, and it’s kind of just bit by bit expanded like that.

Des: So there hasn’t been any key growth activities. You didn’t go viral or anything?

Garrett: No, definitely not. In hindsight it was a mistake to make all of the accounts heavily sandboxed instead of trying to add an element of sharing to it. It’s turned out well, but I definitely think if I could go back I’d try to make it so that the accounts could interact more seamlessly and kind of enable that kind of growth.

Des: Today, you have thousands of active monthly customers. Do you get lots of requests, feedback, et cetera?

Garrett: Absolutely. The feature requests have never ended and, last time I checked, they’re still going. Probably something like 60% of our emails are related to feature requests.

Des: Do you think that’s a function of how simple you’ve kept the product?

Garrett: I think it’s a combination of things. It’s driven in part by the fact that I have kept Sifter so simple that there are a lot of features to be desired. The other part I think is the target audience, being that it’s developers and the sort, they’re the type who are definitely wired to think in terms of features and how to execute on ideas or how to improve things. So they naturally just have a lot of ideas bubbling up. And then finally, it’s probably just related to the fact that anytime anybody emails me, I reply to something like 91% of our emails in under an hour.

Des: That’s pretty impressive.

Garrett: That’s not just a yes/no reply. That’s always a pretty in-depth reply, almost starting a discussion about the feature. Every time I get an email, even if it’s something I thought about before, you know, even if it’s later that evening, I still set aside time and think through it and think “Is this still the right decision? Has anything changed?”

Des: Right. What’s the most frequent request that you know you’re probably never going to do?

Garrett: A month ago, I would have said text formatting. But I think there’s a chance we might put in some form of text formatting. I don’t know when or how.

Des: You mean like bold and italics, that sort of thing?

Garrett: Yeah, we’ve dabbled in it and we’ve explored it and it’s certainly probably one of the front-running requests. There are some consequences to it. Even the current Basecamp implementation, I was writing something in there on somebody else’s account and trying to use it, and I just tried to bold something, or unbold it, and all of a sudden everything got all wonky and I had to reload the page.

Des: It does seem like WYSISYG and others, those sort of things, they do seem like a serious iceberg in web applications. What the user see is tiny in comparison to the development effort.

Garrett: Exactly. It’s a very ugly, nasty problem. I don’t want to just toss it in just to make people happy, because ultimately they’ll end up more unhappy with a poor solution than they would with no solution at all.

Picking Price Points

Des: Let’s talk about pricing. In your book, you outlined a lot of different lessons you learned along the way. You’re currently at a situation where your smallest plan is $29. How did you get there? Did you start it cheaper?

Garrett: We originally started with a $14 plan as well. Over time we realized that the $14 plan really wasn’t pulling its weight. Especially as obsessive as I am about really providing good customer support and getting back to people and having in-depth conversations with people. The $14 plan just made it difficult to really hold up and deliver on our end of the bargain if we’re losing money on a certain swath of customers.

Des: Would your definition of losing money be that the support cost of these additional customers wasn’t justified by—

Garrett: Yeah, it was all driven by the support costs. The biggest cost to support isn’t necessarily the cost of answering them so much as the opportunity cost of every time I’m answering a support email, it’s taking me away from doing development work or otherwise improving the product. Our $14 plan produced the highest volume of support requests from the lowest lifetime value, so the corollary was basically we were spending a lot of opportunity cost on customers who probably weren’t going to use Sifter very long, so ultimately we were losing money on them.

Des: When you dropped the $14 plan, did that affect your sign-up and conversion rates?

Garrett: Yeah, definitely. Our original goal was simply thinking well, if we remove the $14 plan, if even half of those customers that would have signed up for the $14 plan still sign up for the $29 plan, then we’ll come out ahead—well, at least break even. So we make the same amount of revenue on half as many customers, at least in that class.

Des: And how did that work out?

Garrett: Our conversion rate from site visitor to trial plummeted. It decreased by 50%. So we had 50% fewer trials signing up. However, our total amount of $29 plans skyrocketed. Fewer people signed up but the ones who did were much more likely to sign up, and they were fine going ahead and signing up on the $29 plan. We were definitely were happy with how it worked out… lots of the customers who would have signed up for $14 went ahead and signed up for the $29 plan without skipping a beat.

Des: Did you ever consider a free plan?

Garrett: No. We have thought about bringing back a very cheap plan. Based on my experience, if you’re charging less than $10 in the business space, that might as well be free. Charging money is just there to make sure that people are at least a little bit engaged in the system. A lot of people use anything if it’s free, so by putting a little bit of a barrier there, you tend to kind of pre-qualify customers.

Des: You don’t charge per seat, which the other issue trackers do. Why not?

Garrett: My philosophy is that the most valuable feature of any kind of collaborative software, but in particular bug and issue tracking, is participation. That’s not really a feature that you can factor in like other features. It doesn’t matter how great the issue tracker is. If nobody uses it, then it’s not going to work.

Des: When you look at Sifter and think about it over the next five years, what big challenges do you see? Are you worried about someone else coming in and gobbling up the sort of simple market space, or do you think you’ll take the product upmarket and add some of these bigger features?

Garrett: We’ll add some features. The market is already so incredibly fragmented and it’s a market I don’t believe is ever going to be unified because there’s just too many different preferences, team sizes, technology stacks, development processes and workflows that it’s more like Goldilocks where, you know, this porridge is too hot, this porridge is too cold, this one’s just right. Every team is going to be so different.

If anything, we need to do a better job of simplifying our existing feature set. Not to say removing features, but making the existing stuff work 10 times better than it does. So we’re going to add some other stuff for sure. In particular, we’ve been spending a lot of time on our API so that Sifter becomes a better neighbour with all of the other tools, whereas right now it’s an iceberg all on its own.

Other than that, a lot of what I want us to do is to invest in resources and just helping people learn how to do an appropriate level of bug tracking given their team size or project size or whatever the factor is for them.

Des: That’s an education challenge for you, right? You need to effectively teach your customers how to best make use of their time bug tracking.

Garrett: Yeah. It’s not even going to be purely about showing you how to use Sifter. It’s going to be about bug tracking, and if Sifter’s right for you, awesome. If it’s not, then hopefully you at least know some more. I’d love to see us grow, but I don’t want to see us grow and get people who don’t like Sifter. I want to see us grow to people who like Sifter, and if Sifter is not right for people, I want to see them happy somewhere else rather than see us trying to make a few extra dollars.

Des: What sort of stuff are you considering for educational resources?

Garrett: We’ve always blogged. That ebbs and flows with how deep I am in development. The first thing we want to do is create content for reading, then potentially a week-long email course, where every day we send a blog post via email. Let people opt into those free courses.

Where to from here?

Des: Have you ever considered a second product?

Garrett: Definitely. We talk about it all the time. But we feel like there’s so much room left with Sifter. I was even afraid of writing a book. But adding a second product just creates a whole other layer of distraction, and I feel like for us to create another product like that is almost like saying, oh, we feel Sifter’s perfect and doesn’t need to improve.

Des: So, what motivated you to take time away from Sifter for the book?

Garrett: I’d been blogging about some ideas and had always gotten good feedback. People say things like “I’m in that exact same spot you were five years ago.” People just—they appreciated that stuff that I was sharing so I figured I could probably write a book and make this a lot easier on other people.

I figured if I could go back in time and tell myself everything that I know now, I would’ve probably shaved months of effort off my life and a lot of misery.

Des: What are the key lessons that you’d love to get into a time machine and tell yourself?

Garrett: At one point we encountered some fraud. Somebody was just validating stolen credit card numbers using the credit card form on Sifter, and out-of-pocket, it cost us maybe $200 in credit card fees. You know, really nothing in the grand scheme of things. But for two whole weeks, it just drove me nuts. In reality, all we needed to do was just stop it and move on. Another time lost about eight hours of customer data. We thought we had enough data redundancy. We had backups. You know, everybody’s always got backups. Our backups just weren’t robust enough. And we had never really thought about, oh, there’s just so many scenarios for losing data and things that can go wrong. And in this case, at the time we just didn’t have thorough enough stuff.

The Numbers Before the Business

Des: Included with the book is a detailed SaaS planning spreadsheet. Did you create that for this book?

Garrett: No. A version of it was used when deciding whether we would try to build Sifter. We just made up a bunch of numbers, threw it in a spreadsheet, and said “That looks good enough. Let’s try it.”

Des: And that’s what you did. It’s been really interesting to hear about the background, because Sifter is a well-known product but is so very far from being an overnight success. Five years of blood and sweat and hard work. I think you said there was an inflection point, possibly three or four years in, where you actually got back up to where your original salary was?

Garrett: I think just this year we finally gave me a raise and brought me back up to where I was. At the same time, I know just through conversations with other people that I’m still underpaid relative to what I could go make right now. That’s one of those things.

Des: Do you ever draw projections to see at what point will you be like well above where you need to be?

Garrett: You mean where I’d be compared to if I had just made a real salary this whole time? I haven’t. I think here and there I’ve thought about it for like 5 or 10 minutes. When things were tough, I’d really be tempted. “Why do I not have a regular job with health insurance and benefits?” You know, wow, that sounds so attractive. Ultimately I always realise that I’d rather do what I’m doing now than make more money, without a doubt.

Des: Yeah. I think it’s good you feel that way for the sake of Sifter’s users, as well.

Garrett: Oh, yeah, absolutely. Well, now it’s definitely getting on track to where hopefully someday in the next five years, the money won’t even be a factor at all. But even if it was a factor, it doesn’t bother me. I’ve never enjoyed working on something this much. You know, I’ve never had so much stress and worked so hard, but at the same time, I’ve never felt more fulfilled or more sure of the fact that what I’m doing is what I should be doing.

Des: That’s great to hear. Thank you so much for your time, Garrett. It’s been great having you, and I’ll be sure to link up your book and your product, as well, in the show notes. Thanks so much for your time.

Garrett: Great. Thanks for having me.

More from Garrett

Garrett is on Twitter, and keeps both a personal blog and a product blog, and even finds time to post great presentations on Speakerdeck.

There are 2 types of disruption

Often CEOs declare their product to be disruptive, but fail to define in what manner. There are two types of disruption, and each one has a different measure of success. It is possible for a product to be disruptive in both styles but, if that is the plan, then progress must be measured accordingly.

New Market Disruption occurs when a product addresses non-consumption in an existing category, i.e. it is available for customers in a way the incumbents aren’t.

It could be cheaper, available in more places, in more countries, in more languages, etc. For some reason there are customers who can’t use the existing products, but they will be able to use this new one.

You can only claim your company is disruptive through new markets when the majority of your customers are unable to use any of the incumbents in the market.

Ryanair, the low cost airline, created an entire new market of budget travellers, not by stealing customers from Lufthansa or KLM, but by offering routes no one else did at prices that competed with trains and bus routes.

Low End Disruption is when a product steals the cheapest and worst customers from the bottom of an existing market, usually by figuring out a business model that works with a lower-cost offering. This opportunity presents itself when the leaders of the market are producing products far above what the market wants or needs. It’s also important to note that cost refers to “cost of use”, which is not necessarily financial. For example, it’s cheaper to tweet than it is to blog.

The product is clearly lower quality but the switching customers don’t notice or care as they are over-served by the existing products.

You can only claim your company is low end disruptive when you have a working and profitable business model that is stealing low value customers from incumbents.

An example of this is the Flip digital camera which stole customers from the digital camera companies by being more affordable and easy to use. Bought for $590,000,000 by Cisco, Flip was the darling of the camera industry, the poster child of low-end disruption. What could go wrong, right?

It turned out there was an even worse video camera at an even lower price point that the public were happy to use: the free camera found in iPhones and Android phones. 2 years after its acquisition Flip got to experience low end disruption itself. It was shut down, and 550 employees were made redundant.

This happens quicker than you’d think, which brings us to the next point.

Disruption can be swift

The seminal examples of disruption are things like Intel processors, steel mills and mainframe computers. This creates the impression that disruption takes years, even decades to fully impact an industry.

But that is not the case. In a world of online retail, app stores, and instant global availability market adoption takes minutes, not months. Whenever you see a claim of “fastest selling X in history” always remember that adoption is very quick these days and it’s accelerating. For example, Windows 3.1 sold 1 million copies in 2 months. Windows 8.0 sold 40 million copies in less than half the time.

Flip, as explained above, spent a mere 18 months at the top of the market before capitulating. Another example of is that of the satellite navigation companies Garmin and TomTom. In September 2007 they were worth a combined 38 billion dollars. A mere 12 months later, they weren’t even worth 8. What happened? The iPhone.

A 38 billion dollar industry loses 3/4 of its market cap in a year because someone decide to add a maps app to the home screen. Like I said, this happens quicker than you’d think.

If you’re claiming your product is disruptive and there aren’t barriers to adoption (e.g. technological/infrastructural barriers, existing long term contracts, language barriers, price barriers etc), then you should be expecting a massive adoption rate at a high speed. If you’re seeing slow adoption over time you can still have a successful billion dollar business, but it’s probably not a disruptive one.

Low Price Alone is not Disruptive

Disruptive innovations stem from technological or business model advantages that can scale as the business move upmarket in search of more-demanding customers.

Often you’ll see a new business appear offering for pennies what others charge thousands for. The above example highlights this. While a roadside motel offers the same product as the Four Seasons, it will not disrupt it, because to attract the customers who visit the Four Seasons it will need better locations, better gardens, better staff, and better facilities. In short, it will need to adopt the identical cost structure of the Four Seasons, meaning it could no longer out-price them.

The web version of this can be seen every few months when a new stock photography site appears, selling imagery for $1 per picture and claiming it’s disrupting GettyImages. Again, to move upmarket and appeal to magazines and high end design houses, they need to start hiring more talented photographers and offering a wider range of imagery. Doing this would see them adopt the Getty Images cost structure, and therefore not disrupting them.

There is, however, an opportunity for new market disruption here, in that plenty of the market will pay for 600px images to use in blogs and newsletters, are less quality sensitive, and cannot justify high costs per article or newsletter.

A Business Doesn’t Need to Disrupt

Not all successful businesses are disruptive ones. It’s entirely possible to just go toe to toe with an existing business and beat them at their own game. This can happen in lots of ways: better technology, design, product, route to market, price, etc. This is described in the graph above as “sustaining technology”, and is a well proven way to take.

If you are claiming your product is disruptive, keep note of 3 things. You have to decide what way it’s disruptive (so you can measure success), you don’t necessarily get a long time span to do your disruption, and if being cheap is your only angle you’re not disruptive.

This isn’t as easy as blindly screaming disruption every time someone launches “Spotify for Dentists”, but it’s worth considering nonetheless.

You can grab an MP3 of the file here, or there’s a full transcript below including imagery we created to visualise some of the concepts being discussed.

Des: Josh, could you introduce yourself to our readers and listeners?

Joshua: Sure. I’m a product and interface designer. I work at a company in Boston called HubSpot that acquired a company that I co-founded called Performable where we make software for professional marketers. I’ve been involved in design and the web for a long time; I’ve written a blog called Bokardo for 13 years. That’s how most people know me, they’ve read something that I’ve written there.

Wireframes are dead

Des: We’ve a few different topics we’d like to talk about. Maybe let’s just open up with a controversial one. Only about two weeks ago, you tweeted that “In case you didn’t get the memo, wireframing is dead and prototypes are the only way forward.” Obviously Twitter forces you to be concise, but even so, that’s pretty piercing. Can you expand on what your thinking is there?

Joshua: I want to be even more controversial. That statement is like 2 or 3 years late! Often I’ll just like throw out a statement on Twitter, to get first-blush kind of responses. So, there’s a little bit of that in there, but to get more specific, wireframes which are medium fidelity, grayscale, outline representations of an interface. I just don’t see the need for them in any real design workflow anymore.

The reason is twofold. One is that I think you can capture almost everything you need to capture in a pretty detailed sketch. Not a high fidelity sketch by any means. Not the ones where you use five different kinds of markers and you shade everything or whatever. The purpose of sketching is to communicate the major ideas, like, “What’s going to be on the page? What are the objects on the page? What are the things you can do to those objects?” Right? So, what are the nouns and verbs? And you can do that pretty darn well with a sketch, you know, white-boarding.

So I think that most of the things that people use wireframes for, in terms of visually laying stuff out and communicating pieces, can actually be done in sketches.

On the other hand if you want to actually test something, you need a prototype that someone can test. So, I would actually say that the role of the product designer is working with stakeholders to come up with those sketches, and then going right from that sketch all the way through to prototyping. That usually means high fidelity mockups that can be clickable or lightweight HTML prototypes that are clickable and usable. That’s really how I see workflows going forward. Almost every person that I talk to, who I think is doing decent design work, is doing it that way. I think wireframes are mostly a communication tool that is unnecessary, except in “big work” really.

Des: If I was to flesh out what you were saying there, it seems that if you want to try different ideas for layouts, use a sketch, but if you’re testing interactions you need a prototype. Is it possible that the only remaining advantage of a wireframe is that it’s an acceptable, shareable form of a sketch in a professional relationship?

Joshua: Yes. I would say that that’s probably what they’re mostly used for, and in a lot of people’s work that’s perfectly acceptable. I personally would not pay for wireframes, as a deliverable—but, you know, I did consulting for many years. I made wireframes over and over again, as deliverables, and I handed them off and they were passed around and they came back with feedback and all that. I think there’s definitely a need for them in some workflows. But I would fight extremely hard to remove them from any new project that I am involved with. There are other ways to solve the problems that wireframes solved. You just pass around sketches. We create digital representations of sketches all the time at work. Just shoot them with your iPhone. We take pictures of whiteboards, like every day.

A colleague of mine, Dan Ritzenthaler wrote up a nice blog post about this. In it he made a really great point: if you need to create wireframes so that other people can talk, you’re not talking to the right people. You’re probably not talking to the right stakeholders and that’s actually a problem that you need to solve. You need to have direct contact with the stakeholders.

Des: You’ve hit the crux of where the perceived value is and why it could and probably should be replaced. I often feel that the most exciting stuff happens before and after the wireframe in that the wireframe is just like the shareable artefact of a really, really valuable design session and, ultimately, ends up in the bin, once it gets taken any further whatsoever.

Joshua: It’s very similar to the results of usability testing. When I worked at User Interface Engineering with Jared Spool and the gang there we were paid very good money to write these enormous reports, but the thing was, that’s just actually for posterity’s sake. The real job is communicating the results immediately to the design team. If we’re not doing that, then no report is ever going to create empathy. I heard wireframes and some other things called “bill-liverables” the other day. Deliverables that you bill for.

Des: So, tell me this then. In HubSpot I assume you guys don’t rock around with hundreds of wireframes or 300 page PDFs getting passed around the hierarchy. How does your design process work? Are there any deliverables along the way?

Joshua: Am I walking the walk? Totally fair question. Outside of sketches and workable prototypes we have no deliverables. We work with like seven or eight product teams, and each one of those product teams has a product manager. Our best work is done when a designer and product manager essentially are on the same page every day. The way that I’m kind of thinking about it these days is: People who sketch together, get along.

People who sketch together and do that ideation phase of sketching where you take these concepts in your head and you draw them together. That is this really powerful moment, because you can’t lie and you can’t deceive in sketching.

If two people are talking for a week or something, about a new product, they actually might have very different conceptions about that product, even though their language was kind of the same. But once you get down to that level of sketching together, then there’s very little deception that can occur. So, that’s my mantra lately. People who sketch together get along.

Remote Working for Design Teams

Des: That makes sense to me. Here’s a question: Where does this fit in terms of remote working? Can you sketch remotely?

Joshua: Geez. Can you sketch remotely? That’s a great question. I haven’t really tried it. Yes. I haven’t tried it. I would say that it’s possible but it probably won’t be as efficient. You know?

Des: That would be my guess. I think you can throw back and forth photos, but the bandwidth and timeliness is reduced.

Joshua: That’s actually an important difference that you made, Des, that when you have to send something back and forth, it becomes a synchronous, linear process. “I’m waiting for you. Now you’re waiting for me.”

Des: Yes. It’s like you’re passing a ball back and forth, rather than like playing side by side.

Synchronous and Asynchronous Design

Joshua: It’s a different interaction than if you’re doing it at the same time. This is relevant because of the Yahoo brouhaha where Marissa Meyer said no-one could work remotely. Technology is getting to the point where it will feel like you’re in the same room with someone, and you’ll have like super big LCDs where you can see in good fidelity the sketching someone else is doing on a panel, 1,000 miles away. That will definitely come. I think doing it at the same time is actually the most beneficial part and it’s more important than the fidelity of anything you can pass back and forth.

Des: Yes, but no software is going to solve the timezone problem. You’re in Boston. It’s 9am for you, it’s 3pm here in Dublin. Your day is starting, mine is ending. In the early days of problem-solving, you really need like everyone working together, in the same time, sort of preferably in the same sort of humour at the same time of the day.

Joshua: Even with our design team, when we share something, be it on HipChat, LayerVault, or Invision, the feedback is never that great. It tends to be like “Yes, okay, I see that” but they just weren’t in the moment. People can talk way faster than they can communicate electronically, and all of those extra variables that human interaction give us, like tone of voice, inflection and body posture, language and all that, you cannot discount any of that.

The thing with Yahoo! People are looking at it like: “Oh. Yahoo is saying remote is bad and, therefore, they’re condemning that practice for everyone.” I wouldn’t look at it like that. Being part of companies who would try to create cultures has actually taught me a lot about the value of culture and the difficulty of doing it right.

Yahoo is making this decision for their company at this moment in time. They’ve accrued a tremendous number of bad habits over the last decade. Everyone knows the company is in trouble. This is just one of the ways that they are making a hard stance and saying, “You know what? Our culture is going to be a culture of working together in the same space. That’s it.”

I don’t think it’s a general statement on working remotely. I think you can still work remotely and be fine and it depends on the individual. It depends on their lifestyle. It depends on a whole bunch of things. For Yahoo, I actually think it’s a good choice that Marissa made, to do this. In fact, I think it’s the right choice in their case, because they need a huge direction change.

Des: I think the magnitude of changes they need are never going to be comfortable changes. You can’t turn a company around as much as Yahoo! needs to be turned around, while keeping, not just all the Yahoo employees, but all of the onlooking tech bloggers happy.

Are you testing interface, or ideas?

Des: Let’s bring it back a bit. What about testing in Hubspot? Do you guys do much new testing in that regard? Do you test sketches or prototypes?

Joshua: Yes. We rarely test sketches. However, the vast majority of usability testing we do is actually remote usability testing on clickable mockups and working prototypes.

Des: When you say “working prototypes” do you mean HTML, CSS stuff, JavaScript?

Joshua: Yes. We’ll do clickable mockups, or coded prototypes. I have found, though, there is this difference between types of problems that you’re trying to solve. I have seen people test prototypes that were bad ideas to begin with, so we’ve wasted time there. We wasted time building out a bad idea. Nowadays the first thing that we try to figure out is “Are we testing the concept, or the interface?”

Usability testing works best when you know the idea is good and you’re just testing to see if this interface allows that idea to happen.

So, we’re doing a lot more testing early at the sketch phase. We’re doing super-fast interviews with people. Here’s an example: we had this marketplace where you could buy services. Redesign a website, help you do your marketing, write blog posts for you, that kind of thing. We were pushing hard in that space asking “What kinds of services can we offer?” People are always obsessing over subject lines of the emails, so we wondered would people pay for a service where someone writes subject lines for them.

So, we did these mockups and we spent time designing it out. We got people in and they said “I would never use this.” It was such a quick thing. So, what we realised is that we needed this earlier check to see like, “Is this the right type of concept? Is this concept a good one or not?” So, that type of thing is very easy to test, and all I have to do is just ask people, “When’s the last time you paid for someone to help you write your subject line?” It turns out that no one’s investing in that at all. No one’s paid money. So, that’s one of those examples of an existing activity is a pain point, and it’s frustrating for people and they’ll actually go find, you know, marketing materials that will help them write them better, but they will not invest in it.

Des: What’s interesting there is that you’re drawing a distinction between two types of testing. One is “Given that the person wants to do this, is this a good way to do it?”, another is “Would anyone actually want to do this?”

Joshua: Exactly. That’s a nice concise way to put it.

Des: That type of approach comes more naturally when working on your own product, as opposed to when you’ve been hired to test something. If you’re hired to do a usability test of a travel website, you’re just going to do what everyone else would do. Round up people who use travel websites and see if they can use this one. The site can score 100% in testing, but still flop on the motivation. A well designed product that no one wants to use.

Joshua: And they’ll tell you, “Hey, you know what would be awesome? You could add this and you could do this. If you do this, I might buy it.” Then, you finally ask them that core question and then you find out that you just wasted like the last hour asking that.

Des: Is this a fundamental shift? A lot of what we’ve been talking about here is how standard UX techniques don’t map to what you’re doing when you’re designing and building software outside of a consultancy setting. Are “UX designers” meant to be consultants, whereas “Product Designers” are ones who design in house?

Joshua: Good question. You know, I call this “the agency problem.” When you’re an agency, you’re hired to come in and build something. Then, it launches, and you’re done. Your project is done. I don’t think this is effective, because engagement and actual use has become the success metric. There is a longer-term shift toward engagements where the consultancies or agencies will go well beyond launch, through iterations and improvements.

The future of metrics & measurement

Des: That leads me onto the next point, which is, what is a good metric today? If we just obsess over short term quick reward metrics, like sign-up funnels, on one hand it’s great as agencies can immediately track improvements, but on the flipside they’re bad proxies for behaviour. Especially SaaS businesses these days where the idea is: get them signed up, get them on a free trial, get them engaged, get their teammates onboard, then at the end of all that talk to them about a price plan.

Do you think the world of web analytics and business metrics is changing a bit?

Joshua: Yes. I actually think that you and I are working at companies that are trying to push this idea forward. Every part of the user experience can be cut up into small funnels and you can optimize each one of those funnels to be better. That’s what design will become: “Hey, your job is to improve the on-boarding process. Your job is to, you know, re-engage lost customers.” You know, and that’s the problem that designers will be put on and then they just have to figure out everything around that experience, to get that metric better.

That’s the way I look at the world. You know, I’m pushing hard at HubSpot to build that through all our marketing materials and then our software. In terms of metrics, I think engagement is still huge. But to answer your question, I think the high-level metrics will be at the company level and we’ll have to build software that connects those metrics with the actual touch points of the entire customer experience.

Des: What you’re proposing would be that effectively global metrics are company-wide figures, but that any individual designer will be tasked with their own set to influence? So for example, if you’re redesigning the invites screen, the metric of success is the number of teammates invited here.

Joshua: Exactly. Do you see how that completely changes a lot of people’s notion of a designer?

Des: I do. A while back I wrote about three ways you can improve a product and how you have different goals, depending on what you’re doing. You’re always shooting for one of three, two of them are easily mapped to metrics:

1. Make more people use the feature.
2. Make those who use it, use it more often.
3. Give a better experience to those who use it.

Joshua: Yes. I actually like the way you described that, because it points to the very specific metric that you’re looking to improve. “Is it a ratio that I’m trying to improve?” which is, like, of the people who are sharing, can they share better? Or “Is it like a number that I’m trying to, you know, increase?” I like that. I like that framework. A few years ago, when I last went to South by Southwest, I gave a talk called “Metrics Driven Design” and one of the fascinating things when talking about metrics in design is that it actually scares the hell out of some designers. Like it really, really scares them. That some metric will be what they’re accountable for. What I found over time is that actually makes me feel way better about doing design work. Like, “Please, give me a metric. I will go, you know, toe-to-toe with that metric and figure it out.”

To me, that’s a much more clear-cut, approachable problem than “Oh, you have to just make it look good until people are happy and they don’t complain anymore” or whatever the alternative is.

Des: Exactly. I think that’s another great example of the sort of work that you can’t necessarily procure from a consultancy, because you actually need someone who’s going to be around for long enough to understand what a ratio is and where it can go or understand where the metric is and where it can get to.

Joshua: Yes. Exactly. I think that’s going to be a huge part of the changing role of designers, that it will be kind of like, “Hey, here’s a metric. Go tackle it. Just go climb that hill.” I think designers will actually love that. You know, designers love solving puzzles and that’s all metrics are.

Des: The part of metrics where everyone got offended was the whole “41 shades of blue” type assessment. However, if the challenge was: “Make sure everyone can quickly send and reply to as many emails as they want”, then metrics aren’t offensive. Everyone is on the same page.

Joshua: The 41 shades of blue is just the perfect kind of crystallisation of the problem.

Des: Yes. Exactly. Lastly, You’re writing a book or two at the moment. Can you just give us a quick overview of what they’re about. ?

Joshua: Sure. I’ve been writing one book for four years now. I was getting good traction on the book when I jumped into doing the start-up which essentially just killed any momentum I had. As you know, startups are life consuming. When I was writing this book I realized I kept coming back to this “usage lifecycle” that we spoke about earlier. So, I’m going to release a short book first which focuses purely on that.

The key idea is that if you have a product or service that you want to bring to the world, think about your customers in terms of the usage lifecycle. Before they are actual customers, they’re in learning mode and they’re in research mode. Your task—as a designer—is actually selling. It’s teaching. It’s letting people learn about your software. You know, you can do everything from giving them a free trial to show a screen cast of someone using it, to creating marketing materials, to tweeting about it, like all of those pieces. That’s what the book covers.

Des:It sounds like a great concise book to address a specific concept really well. Thanks so much for participating Joshua, lots of good ideas there for our readers and listeners to chew on.

Joshua: Oh. Thanks, Des. Yes. And keep up the great work. I’m a big fan of your blog and I’m honoured to be one of your interviewees.

More from Josh Porter

Josh’s book “Make them care” will be released this year. He can be found on Twitter as @bokardo, and on his personal site is at bokardo.com.