Intercom on Starting Up

I'm currently building an app with my friend and we want to turn it into a startup.

We're making something we want for ourselves, and we hope it's something people want to, echoing what YC says, "Don't make a startup, make something people want".

I found this book Intercom on Starting Up by Des Traynor on Twitter a few days ago, and decided to read a few pages since my internet was down at the club.

I'm focused on 3 questions out of the 9 in the book because it's more relevant for me right now as I'm building an MVP with a friend.

The questions are: what to build, how to build it, and how to find your first customer.

What will you build?

Note: This question is not one you can answer definitively. Even after releasing and getting users, you have to continue making hard decisions about what features to build next, what bugs to fix, what customer request to address.

Ask yourself the following questions before you start designing or coding

  1. Is this a real problem people want solved?
  2. Do I have experience with this problem that will help solve it?
  3. Can I build something that's magical, and is substantially better than existing products?

"Problems first, Technology second."

  • One of the biggest mistake is focusing on the technology, rather than what it will enable.
  • Jobs-to-be-Done (JTBD) framework
    • what? people don't buy your product because of their demographic, they want to hire it to do a job for them
    • All technology flops have something in common. They failed to do a job for their customers.

Innovation has two components

technological innovation and market impact

  • Breakthrough Tech = high technology progress + low market impact
  • Disruptive = high market impact + low technology progress
    • Truly disruptive products don't require a huge technological leap, they just have a much better understanding of what the jobs to be done are.
  • Game Changers = high tech + high market
    • ex: the iPhone, focused on real things people needed to do and showed how they were possible in infinitely superior ways.
    • are first movers, often fail because they don't know how to explain what they've built. make sure to clearly articulate the problems your product solves.

Anticipate but don't fetishize the future

"Any degree of success will breed complacency. Any degree of complacency will breed failure. Therefore only the paranoid survive." – Intel CEO Andy Grove

  • be acutely aware of all the different technological shifts happening, constantly ask how these things will affect you.
  • focus on the technological landscape around you and what's coming down the line
  • pay less attention to homepage of TechCrunch, and more to the changes happening in the industry you're in
  • Ask yourself: Does this tech make it cheaper, faster or easier for our customers to make progress in their lives?

Don't reinvent the wheel

  • great products can be created by tinkering and improving on existing ideas, or making unglamorous changes that don't require new tech
  • double down on what already works, and focus on the first step where you can add value.
  • if you've tried and tested ideas that work, build on them. Customers aren't paying for innovation, they're paying for a great product experience

Three ways software feels magical

great product design is about cost-benefit analysis. How much does the user have to do versus the benefit they get in return? Whenever you find a way to dramatically reduce the cost – time and money – to the user and provide a greater benefit, you're creating something magical

  1. Era of Uber-ification
    • Uber-ification = the slimming down of application interfaces into push-button experiences that do one thing. The next consumerization.
    • one tap or swipe gets you a date, food, a movie, flowers, a job, even a dog.
    • The user's context – time, location, device, previous actions – combined with behavioral analytics and user preferences, can all be combined to offer a simple way to do complex tasks.
  2. End of data entry
    • baseline: shift from recall to recognition, rather than asking users to recall and enter items, let them pick from options
    • real magic: no steps. connect to socials to find my friends, connect to email to find receipts and meetings, connect to bank to analyze transactions.
  3. Ambient awareness
    • great software relies on ambient awareness – it conveys information without you looking directly at it.
    • ask yourself "How can I ensure that every user gets value from this product, even if they forget to log in?"
    • this can be push notifications, newsletters, SMS, daily reports for users to get full value of your product.

How will you build it?

Core principles on building a product

by Paul Adams, VP of Product

  • Ruthless focus on the exact problem you're trying to solve
    • talk to customers and research their problems, perceptions, wants and needs.
    • PMs must be directly connected to customers.
  • Obsess about the smallest thing we can build that we think will solve the problem
    • think big, but scope right back to the absolute minimum.
    • this is a painful process, bu this pain means you're remaining focused
  • Ship to learn
    • shipping is only the beginning of building, ship as fast and frequently as you can
    • don't rune experiments, startups that fall back to experiments to make product decisions aren't focusing enough on the problem they're solving
    • shipping to learn = being confident that you've understood and solved the problem, but humble enough to know you'll only truly learn when it's in the hands of customers.
    • the best product people are obsessively curious after they ship something. they need to know if what they designed and built helped their customers

Guidelines for making decisions

  • many small steps > bigger launches
    • ship the smallest, simplest thing that will get you closest to your objective as fast as possible and help you learn what works.
  • daily and weekly goals
    • everyone should know what their goals are for each day, how they relate to the team's weekly goals, and how they relate to what is being released by the company.
  • optimize for face-to-face collabs
    • two people at a whiteboard = more ideas and reach consensus quicker, remote work is not for speed and efficiency of decision making.
  • fight against "work work"
    • don't use software to build software, fight anything beyond a lightweight process, use the fewest number of software tools to get the job done
  • outcome > plan
    • plans are made with limited information, but things only become fully clear as you execute
    • best teams absorb and react to new info and build great products in spite of changing circumstances.

accountability & goals

  • it must be crystal clear who is accountable for what
  • if it's design: it's on the designer (ensure they understand the research and problem being addressed)
  • if it's bugs, it's on the PM (ensure they test realistic usage and edge cases)

A culture of goal setting

  • set weekly and daily goals to stay focused and on track
  • break weekly goals into daily and sub-daily goals to reinforce the idea that every day counts and the cadence of building matters

A product roadmap

  • next 6 years
    • picture of the world in six years, and how it will evolve as you make changes
  • next 6 months
    • you should be thinking "we're making great progress"
    • about 50-70% of the things on the list might be built, the other 25% are things you hadn't thought of before
  • next 6 weeks
    • immediate plan and what your team intimately understands
    • you know exactly what's being built
    • updated every week or two

Anatomy of a product roadmap

  1. new ideas
    • based on opinion rather than research, not data-driven
    • comes from the trends and ideas you see and what excites you the most
  2. iterate recently shipped features
    • you never get it right the first time no matter how hard you try or how much research you do
    • shipping is just the beginning, iterate and make things better
    • know your success criteria (metrics) before shipping, measure post launch and follow up with customers for qualitative feedback
  3. most common customer problems
    • every week: tag every conversation with customers with a category (i.e. usability issue, feature, request, bug) and tag the team that owns that area
    • every few months, create a "hit list" of most common customer problems
    • use PMs weekly pulse and researchers' analysis to determine which problems to address first.
  4. improve quality
    • two measures for grading issues
      • how server is the problem
      • how many customers does it affect
    • fiercely commit to a high bar for speed, latency and efficiency.
  5. features to help you scale
    • never build a feature to close a deal – this signals the beginning of the end of your product
    • talk to sales team to research new customers and understand the types of features they're looking for

Three principles for shipping

  1. be comfortable knowing new features aren't perfect
    • You can't become good at something without the freedom to be bad at it first.
    • ship things that aren't "perfect", deliberately chose what not to build to accelerate production
  2. carefully define self-contained, well-scoped projects
    • self-contained = engineers can get right to building without understanding the entire codebase
    • well-scoped = able to ship something within a week
    • paint the bigger picture, break it down into lots of smaller pieces that ship bit by bit, gradually replace parts of the experience.
  3. shipping is about learning

    The quicker you can get feedback on what you're thinking, the better your idea will be. Usage is oxygen for ideas. – DES (CO-FOUNDER)

    • you can't predict how users wil behave or react. You give them a basic feature set, observe, and then iterate quickly.
    • you will be wrong more often than being right, prioritize speed to execution

How will you find your first customers?

  • Intercom planted many seeds that led up to their launch, they wrote a ton of articles that appealed to the right audience. They built their own social proof. They also went #1 on Hackernews.
  • the startup curve: any company can get a one-day bump from TechCrunch and quickly end up in the "trough of sorrow" once the novelty wears off

"we don't sell saddles here"

  • Slack CEO Stewart Butterfield's famous internal memo on clearly articulating the vision behind the product
  • ex: if you're building a new email app, people don't care about pixels or shadows or fancy sidebars, they care about the thinking behind the product: how you think about email and how those ideas are reflected in the product
  • to attract a meaningful audience, share the ideas at the core of your product as early as you can. That's what attracts the people who are interested in the ideas and purpose underpinning your product.

word of mouth

  • the most powerful way of getting customers
  • you're more likely to try an app that a friend tells you over coffee than one you see in an ad
  • it's hard to put a price on its value
  • only useful when the same words come out of lots of different mouths

great messaging

blind men and elephant analogy: when people first encounter your product, they will have different opinions of what it does and how it should be used. So it's important to have important messaging so they can easily explain your product.

  1. simple: easily understood by current and prospective customers
  2. compelling: describes something interesting or desirable to them
  3. specific: captures what your product does, not overly abstract
  4. differentiated: includes something that makes it unique
  5. defensible: not easy for competitors to copy

"If you don't have your story and messaging right, no amount of money spent on tactics like paid acquisition will work. You'll bring people to your product only to find a message that doesn't resonate. Getting your story straight is crucial to convincing them your product is going to meet their needs." – MATT (FIRST MARKETING HIRE)