Jason Fried (Jason Fried), David Heinemeier Hansson (DHH), Matthew Linderman (Matt Linderman)

The Starting Line

Build Less

Conventional wisdom says that you have to out build (develop, sell, spend, …) your competitors

This mindset leads to cold war thinking and doesn’t help anyone

The alternative approach is to do less of the big hairy problems and to focus on do the simple ones really well

Less software, features, preferences, people, meetings, promises, etc.

What’s Your Problem?

Solving your own problem is the surest way to build something valuable for others

This is why so many developers work on open source projects --- they know implicitly what good choices are and what bad choices are because they are their own users

Fund Yourself

“Outside money is plan B”

Think hard about what you can do with self funding before becoming beholden to someone else’s expectations (investors)

Use limited resources as a positive constraint to make sure you’re building the right things (no bloat)

Short runways force you to get your idea into the market faster

If it’s good, you soon become self sustaining

If it’s bad you can go back to the drawing board

Fix Time and Budget, Flex Scope

“Launching something great that’s a little smaller in scope than planned is better than launching something mediocre and full of holes because you had to hit some magical time, budget, scope window.”

Benefits of fixing time and budget and flexing scope:

• Forces you to make hard prioritization decisions early
• Allows you to be realistic about what you can deliver at a high quality
• Gives you flexibility to adapt

“It’s better to make half a product than a half-assed product.”

Have an Enemy

Figuring out what your product shouldn’t be is an effective way to hone in on what it should be

As a bonus, picking an enemy leads to a clear marketing message

Caveat: don’t get too obsessed with competition, find your own path

Persuading someone to switch to an opposite point of view requires that they implicitly admit they were wrong

Instead, convince people that you’re telling a different, better story --- not one in direct opposition to what they are doing now

It Shouldn’t Be a Chore

“Your passion --- or lack of --- will shine through.”

Stay Lean

Less Mass

“The leaner you are, the easier it is to change.”

Mass is increased by:

• Long term contracts
• Excess staff
• Extra meetings
• Excess process
• Technology lock in
• The past ruling the future
• Long term roadmaps
• Office politics

Mass is decreased by:

• Just in time thinking
• Multi tasking team members
• Embracing constraints
• Less features
• A culture that can admit mistakes

Low mass companies can adapt more quickly and when necessary, change their minds

Lower Your Cost of Change

“Stay flexible by reducing obstacles to change.”

If a company can’t change as fast as it’s competition it’s in trouble

The companies who can adapt the fastest tend to win

“Emergence” in software development:

Simple rules lead to complex (but elegant) behavior (e.g.: flying birds)

Complex rules lead to stupid behavior (e.g.: the DMV)

Most software development practices try to lock down and optimize the system, this has the unfortunate side effect of limiting emergent (i.e.: superior) behaviors and methods

“Keep it small, keep it simple, let it happen.”

The Three Musketeers

“Use a team of three for version 1.0”

Developer, Designer, Sweeper (switch hitter)

Constraints force prioritization, creativity, and tight communication

Embrace Constraints

“Let limitations guide you to creative solutions.”

Frame constraints as a positive force and figure out how to work effectively within them

“Constraints are often advantages in disguise.”

Be Yourself

“Differentiate yourself from bigger companies by being personal and friendly.”

If you’re small, talk like you’re small

No need for excessive formalities, posturing won’t make you appear bigger or more important

You may be able to fake it for a little while but eventually your customers will find out --- this isn’t the way to build lasting, positive relationships

Priorities

What’s the Big Idea?

“Explicitly define the one-point vision for your app.”

Why does it exist? What makes it different from its competitors?

One sentence should be enough: “Product management is communication.”

Having a strong vision helps keep choices in perspective and everyone moving in the same direction

Ignore Details Early On

“Work from large to small”

Success is in the details but there are also an infinite number of distractions and sticking points

“Just get the stuff on the page for now. Then use it. Make sure it works. Later on you can adjust and perfect it.”

“Details reveal themselves as you use what you’re building.”

(Drawing classes)

It’s a Problem When it’s a Problem

“Don’t waste time on problems you don’t have yet.”

Deferring work on looming problems allows you to work on more important things

When problems become problems, solve them. Not before.

Hire the Right Customers

“Find the core market for your application and focus solely on them.”

Highly focused solutions → highly satisfied customers → evangelists for your product

Scale Later

“You don’t have a scaling problem yet.”

Again, it’s only a problem when it’s a problem

Building for scale early makes it less likely that you will reach that scale

“Create a great app and then worry about what to do when it’s wildly successful.”

Make Opinionated Software

“Your app should take sides.”

Embrace a specific vision for how your product should work, those who disagree can go elsewhere

(Wiki content editing change logs etc.)

Build for the people who have the same opinions that you do, they will be your strongest advocates

Feature Selection

Half, Not Half-Assed

“Build half a product, not a half-ass product.”

Record ‘good’ ideas for later and focus only on what is totally essential

Nail the essential pieces and then use that momentum (and data) to add from there

It Just Doesn’t Matter

“Essentials Only”

(Timestamps, formatting, number of people in a room for chat)

“Most of the time you spend is wasted on things that just don’t matter. If you can cut out the work and thinking that just doesn’t matter, you’ll achieve productivity you’ve never imagined.”

Start With No

“Make features work hard to be implemented.”

Designing, building, releasing, and supporting a feature is very expensive and very difficult to reverse

Feature requests start with ‘not right now’

If they keep coming up only then do we start to even consider them

Hidden Costs

“Expose the price of new features.”

Beware / be wary of features that lead to more features

Explicitly state all of the downstream impacts of adding a feature (marketing, training, support, etc.)

Can You Handle It?

“Build something you can handle.”

Make sure that you can actually deliver on what your product promises

Human Solutions

“Build software for general concepts and encourage people to create their own solutions.”

“Do the best job that you can with the root of the problem and then step aside.”

Forget Feature Requests

“Let your customers remind you what’s important.”

Don’t store feature requests, read them and then throw them away

The ones you want to focus on are the ones that keep popping up

In practice, request tracking isn’t helpful because you already know what needs to be done next, your customers keep reminding you

More people requesting a feature does not necessarily mean you should include it. Sometimes it’s better to say ‘no’ and stick to your product vision

Hold the Mayo

“Ask people what they don’t want.”

Improve through subtraction

Start by removing bloat, only after slimming down to the minimum should you start to add

Process

Race to Running Software

“Get something real up and running quickly.”

Real software bypasses arguments, indecision, incorrect focus, and allows you to focus on the things that actually matter

Disagreeing about sketches is easy, disagreeing about the real thing is hard

This mantra applies to software components as well as full interfaces --- release early and functional (not perfect) components and other developers will want to use them

Rinse and Repeat

“Work in iterations.”

You don’t need to aim for perfection the first time if you know you will go back and do it again later

Our minds are wired to respond to the things directly in front of us (lions). We are much worse at responding to things that are far off or require imagination. Use this by prototyping and building iteratively rather than in far away batches

From Idea to Implementation

Go from brainstorm → sketches → HTML → code

Brainstorm

Big picture, big questions, goals, high level needs

Paper Sketches

Convert concepts into rough interface designs, there are no wrong answers

Create HTML Screens

No code yet, just a high fidelity UI to get feedback on

Code It

Once the mock up looks good (not perfect) start to build it

It’s important to note that all of these steps are iterative --- it’s natural (even desirable) to do each multiple times

If you end up on a bad decision path it’s okay to throw it out and start over

Avoid Preferences

“Decide the little details so that your customers don’t have to.”

“Preferences are a way to avoid making tough decisions.”

Preferences lead to more cognitive overhead, more software, and more bugs

“If you make the wrong call it’s fine, people will tell you about it.”

“Done!”

“Decisions are temporary so make the call and move on.”

Accept that decisions are temporary and mistakes will happen, optimize for cleaning them up quickly, not perfection

Test in the Wild

“Test your app via real world usage.”

Testing beta features with fake audiences and artificially limited feature interactions won’t lead to very useful data

In contrast, releasing in the wild with real users is basically guaranteed to net useful results (the Rails book)

1. Decide if it’s worth doing and if so:
2. Do it quick --- not perfect, just do it.
3. Save it, upload it, publish it
4. See what people think

Shrink Your Time

“Break it down.”

Big chunks conceal a lot of complexity and unknown risk. Keep breaking big things down until those risks are manageable

The Organization

Unity

“Don’t split into silos.”

Specialization is nice but the flip side is that you end up with a bunch of people that only really understand one part of the product / company

Alone Time

“People need uninterrupted time to get things done.”

Alone time lets people get in ‘the zone’ --- where most of the most valuable work happens

Take big chunks of time and designate them, company-wide, as alone time

It needs to be the entire company so that it becomes contagious

Meetings Are Toxic

“Don’t have any meetings.”

Meetings only become necessary when something is too complex to communicate over email. Rather than meeting, spend that time making it simpler (and then communicate it asynchronously)

Meetings are bad because they…

• …disrupt flow
• …are usually about abstractions instead of concrete decisions
• …have a low bit rate
• …are easy for one loud voice to monopolize
• …tend to drift
• …require prep that people rarely do

If you must have a meeting:

• Set a 30 minute timer, when it goes off the meeting is done. Period.
• Invite as few people as possible
• It must have a clear agenda

Seek and Celebrate Small Victories

“Release something today.”

“The most important thing in software development is motivation. Motivation is local.” (every individual, every project)

Long release cycles spread out celebrations and sap motivation

Find four hour quick wins every week or two

Staffing

Hire Less and Hire Later

“Add slow to go fast.”

Hiring a bunch of people quickly leads to all sorts of culture and communication problems

You don’t need as many people as you think you do

Only hire if there is absolutely no other way

Kick the Tires

“Work with prospective employees on a test-basis first.”

Actions, not Words

“Judge potential tech hires on open source contributions.”

Doing this lets you ignore posturing from resumes and references and focus on what matters:

• Quality of work
• Cultural perspective (aka decision making approach)
• Level of passion
• Completion percentage (drive, need to ship)
• Social match (personality)

Get Well Rounded Individuals

“Go for quick learning generalists over ingrained specialists.”

In a small team everyone needs to be able to fill multiple roles

The ability to learn and adapt is key --- tomorrow many need dramatically different skills than today

You Can’t Fake Enthusiasm

“Go for happy and average over frustrated and great.”

Enthusiasm, trust, desire, shared philosophy

Wordsmiths

“Hire good writers.”

Good writing shows a person knows how to communicate, simplify, think clearly, relate to others, and anticipate a reader’s thoughts

Interface Design

Interface First

“Design the interface before you start programming.”

Design is light and cheap

Code is heavy and expensive

Validate using techniques that are light and cheap so that you don’t have to revise using techniques that are heavy and expensive

Epicenter Design

“Start from the core of the page and build outward.”

The epicenter is whatever the page absolutely can’t live without

Start with the most critical pieces and then move on to the second most critical, third most critical, etc.

Three State Solution

“Design for regular, blank, and error states.”

The Blank Slate

“Set expectations with a thoughtful first-run experience.”

Most interfaces are designed when they’re full of data but the user decides if it’s worth using when it’s empty

Get Defensive

“Design for when things go wrong.”

Book recommendation: “Defensive Design for the Web”

The approach applies to both technical and interface defensiveness

Context Over Consistency

“What makes sense here may not make sense there.”

Consistency is great but not necessary. It’s better to be right and inconsistent than wrong and consistent

Copywriting is Interface Design

“Every letter matters.”

The language your app uses should match the way that your audience talks about it

Think about what your labels mean to your users, not to yourself

One Interface

“Incorporate admin functions into the public interface.”

Admin screens tend to look crappy. To avoid this, incorporate admin functions into your client facing interfaces so that they don’t become abandoned or unloved interfaces

Fewer screens = fewer places to get sloppy

Code

Less Software

“Keep your code as simple as possible.”

Complexity increases exponentially with each piece of code added

Fight this by writing less code (and less making features)

Don’t try to predict the problems of tomorrow, solve today’s problems and stop

Wherever possible break hard problems down into simpler, easier to write / support / understand easy (i.e.: small) problems

“Encourage programmers to make counteroffers.”

For every feature: “Is there a way this can be added with less software?”

Optimize for Happiness

“Choose tools that keep your team happy and motivated.”

This is especially important when picking a language for your app

Excited, motivated people build better products

Code Speaks

“Listen when your code pushes back.”

If something is hard and complicated to do it means there is probably a better way

Manage Debt

“Pay off your code and design bills.”

Regularly put aside time to fix debt or you will keep paying interest without ever reducing the principle

Open Doors

“Get data out into the world.” (APIs, RSS, etc.)

“Give up the idea of sealing in data, instead, let it run wild.”

Words

There’s Nothing Functional About a Functional Spec

“Don’t write a functional spec document.”

Functional specs…

• …are fantasies
• …are about appeasement
• …only lead to an illusion of agreement
• …force you to make the most important decisions when you have the least information
• …lead to feature overload
• …don’t let you evolve, change, and reassess

A better alternative:

• Write a one page story about what the app needs to do
• Begin building the interface based on that story (paper prototypes → HTML → code)

Words are easy to misinterpret, interfaces are much harder

Don’t Do Dead Documents

“Eliminate unnecessary paperwork.”

“Unless a document is actually going to morph into something real, don’t produce it.”

Documents / work that won’t (or don’t) become something are wasted effort

Tell Me A Story

“Write stories, not details.”

The story doesn’t need to be super detailed (think strategy, not tactics)

Stories are the seed of a conversation

Use Real Words

“Insert actual text instead of lorem ipsum.”

Lorem ipsum makes you view text like a design element --- a shape --- instead of what it actually is: information that someone needs to actually enter or read

“Do as your customers do and you’ll understand them better.”

If a block of text needs to be read, read it. If it needs to be entered, enter it.

Personify Your Product

“What is your product’s personality type?”

Decide and use those traits to inform your copy, interface choices, and the feature set you build

Pricing and Signup

Free Samples

“Give something away for free.”

It’s a noisy world, giving something away for free helps cut through the noise

Easy On, Easy Off

“Make signup and cancellation a painless process.”

Giving people control over their information builds trust

Silly Rabbit, Tricks Are For Kids

“Avoid long term contracts, sign up fees, etc.”

A Softer Bullet

“Soften the blow of bad news with advance notice and grandfather clauses.”

Promotion

Hollywood Launch

“Go from teaser to preview to launch.”

Teaser

Start dropping hints, approaching tastemakers, and others who like to be ahead of the curve. Collect emails.

Preview

Start talking about features, outlining philosophy and principles, and giving beta keys to select users.

Launch

Email the people who you have been collecting, post about signups and usage metrics, get coverage on blogs, etc.

A Powerful Promo Site

“Build an ace promotional site that introduces people to your product.”

Content ideas:

• Overview
• Tour
• Screenshots and videos
• Manifesto
• Case studies
• Buzz
• Forum
• Pricing and sign up
• Blog

Ride the Blog Wave

“Blogging can be more effective than advertising (and it’s a hell of a lot cheaper).”

Tout your product where you can but your first priority is providing valuable content to your readers

Solicit Early

“Get advance buzz and signups going ASAP.”

Make a basic landing page and start collecting emails as soon as you can

Promote Through Education

“Share our knowledge with the world.”

Give something back to the community that supports you and get some free press in the process

Feature Food

“They’re hungry for it so serve it up.”

Releasing new features is a great way to get in front of specialist audiences

Track Your Logs

“Study your logs to track buzz.”

Find out where people are talking about you and go join the conversation

Infinite Upsell

“Promote upgrade opportunities inside the app.”

Existing customers are the best source of new sales

Name Hook

“Give your app a name that’s easy to remember.”

Short, catchy, memorable, and stick with it

Support

Feel the Pain

“Tear down the walls between support and development.”

Make your whole team get in touch with the outside world --- pop bubbles

Zero Training

“Use inline help and FAQs so that your product doesn’t require a manual or training.”

“Strive to build a tool that requires zero training.”

Answer Quick

“Quick turnaround time on support queries should be a top priority.”

Responsiveness (even if it’s an answer your customer doesn’t want to hear) can often shift anger into appreciation

Tough Love

“Be willing to say no to your customers.”

Don’t be a slave to feature requests. If you add everything someone asks for then no one will want to use the product

”[Basecamp’s] number one request … is to keep things simple.” (despite constant feature requests otherwise)

As a software company, it’s crucial that you love your product --- this won’t happen if it’s filled with a bunch of stuff you don’t believe in

In Fine Form

“Use forums or chat to let customers help each other.”

Publicize Your Screw Ups

“Get bad news out there and out of the way.”

“Customers are usually happy go give you a little breathing room as long as they know you’re being honest with them.”

Deliver bad news quickly and, if you can, deliver good news slowly over time

Post Launch

One Month Tuneup

“Issue a major update 30 days after launch.”

Lets you continue buzz, and gives you an excuse to deliver a leaner V1

Keep the Posts Coming

“Show your product is alive by keeping an ongoing product development blog post launch.”

Weekly or more if possible

Tips, FAQs, features, press, etc.

Better, Not Beta

“Don’t use ‘beta’ as a scapegoat.”

Private betas are fine but if it’s not good enough for public consumption then don’t release it to them

All Bugs Are Not Created Equal

“Prioritize your bugs (and even ignore some of them).”

“If customers complain about a bug, be straight up with them. Tell them you’ve noted the issue and are dealing with it. If it won’t be addressed right away, tell why and explain that you’re focusing on areas of the product that affect a greater number of people.”

Ride Out the Storm

“Wait until knee-jerk reactions to changes die down before taking action.”

Almost every change (even ones for the better) lead to outrage somewhere

Wait 24—48 hours for things to settle down before deciding to do anything drastic

Keep Up With the Joneses

“Subscribe to news feeds about your competitors.”

Beware the Bloat Monster

“Mature doesn’t have to mean more complicated.”

Don’t add just for the sake of adding

Go With The Flow

“Be open to new paths and changes in direction.” (Flickr, Slack)

Conclusion

Start Your Engines

“Success is all about great execution.”

To execute well you have to combine all of the elements well: code, design, promotion — the key is balance

The most important factor of all, though, is getting the right people

People who are…

• …passionate about what they do
• …think about their work as a craft
• …sweat the details when no one is looking

Once you’ve internalized these ideas you’ll find them popping up in a host of other domains across life, look for those areas!