We're designers and developers. We want to design and develop software. Before
we can do that, we need clients to hire us.
The overall process is:
- Someone contacts us via
our new project form,
phone, or email.
- We have a video call or have them come into the office.
- Qualify/disqualify: are we a good fit for the client?
- Qualify/disqualify: is the client a good fit for us?
- Understand the client's vision.
- Agree to the outcomes we're trying to achieve.
- Estimate iterations.
- Sign the contract.
- Pay us for the first iteration.
- Schedule people for iterations.
- We begin work.
Our leads often come from referrals from
We track each lead in Zendesk Sell.
We manually create Contacts for personal introductions. Our new project
form automatically creates leads for each
The Managing Director in the location will get notified about the incoming lead,
but anyone can take responsibility for it. The person responsible qualifies or
disqualifies the lead, often with a quick intro email, phone, or video call
with the potential client, before they move the lead forward in Sell, which
will change them to the owner.
We prefer to pair on sales calls, having at least one designer and one developer
on the call. This enables us to get multiple opinions on how good or bad of a
fit the client and project might be for us, it gives us the ability to answer
both design and development questions to the best of our ability, and it allows
us to train and improve our process during sales calls.
Understanding Product Vision
Our goal is to begin thinking about the client's product and working as a team
to plan it even before we officially start working together. Some example
questions to ask:
- What's unique about this product?
- What big benefit does the product provide?
- What pain does the product alleviate?
- Who currently buys this product?
- Who do you want to buy this product?
- What do customers love about your product?
We distribute the sales process throughout the team. Potential clients should
be able to talk to the people they'll work with. We should be able to handle
spikes in incoming leads that make it unreasonable for a Managing Director to
respond in a timely fashion.
We use an internal app to manage our schedule and availability. We don't track
time, but we do plan in week increments.
If the client asks us to sign an NDA, we respond with:
Are you willing to chat without signing an NDA? We've worked with hundreds of
clients. We talk to hundreds of potential clients each year. It's inevitable
that we hear similar ideas.
If the NDA is important to the client, ask them to tell us enough about the
business to evaluate whether there's a conflict with our existing or past
clients. If we determine there's no conflict, the project is a good fit, and the
NDA is mutual, we sign it. If their NDA is not mutual, we use our
We offer some combination of designers, Ruby developers, and iOS developers. An
advisor assists the team for a few hours a week. Everyone is
T-shaped, deep in some area of
expertise with the ability to collaborate across disciplines.
We are people, not "resources", and avoid calling each other such because we
understand we are working with each other as people.
The designer is responsible for designing interactions between users and the
product. They write user interface code.
The developers make it work. They write the code that makes the app "smart."
They aim to make the product error-free. They monitor performance because speed
is a feature of every application.
Developers keep it running. They make architectural decisions and interact with
modern-day hosting companies like Heroku, whose employees
double as our outsourced operations team.
Ruby, SQL, and lots of other code. They set and meet development standards, keep
passing, and review each others' code.
The advisor adds an impartial perspective. They run weekly meetings so that
there is consistency in week-to-week communication. They keep an eye on the
high-level goals of the project, which should be easier for them because they
are not in the weeds of the project day-to-day. They express enthusiasm when the
team is in a groove and help problem-solve when things get off track.
When appropriate, they should work with the client to either reduce or increase
team size to correctly serve the project.
The advisor is not a project manager. Nor do they take the primary
responsibility for the project away from the team. The rest of the team does
not report to them. The advisor is also not a technical or design lead.
Additionally, the advisor may:
- help the project team work together to form an initial backlog, probably
about 2-3 weeks worth of stories,
- identify specific behavior from the client or team they think might
signal a mismatch in understanding and bring it to everyone's attention,
- run a training session for the client on the finer details of working
with us, e.g.: what makes a good story, how to bring concerns to the
team, walking through complexity vs. planning, and how we would advise
dealing with it,
- coach the client over the first two weeks in terms of how we might need more
input in some places, but less in others.
Anyone at thoughtbot should be able to advise a project. If the primary
salesperson is not also the advisor, there should be a detailed hand-off from
one to the other so that details are not lost as the team starts the project.
There may also be a separate account manager for a client. This may happen if
the account manager typically led the initial sale, but is not the advisor, or
if a client has multiple projects with multiple advisors. In these cases, the
account manager is responsible for maintaining a lifetime relationship with the
client. They understand the client's needs and budgets, and how thoughtbot can
meet those needs. They identify opportunities for working with a client, they
coordinate scheduling, and manage invoices for the client's projects.
While each person plays a role, a team needs to be a team.
Everyone takes responsibility every day for delivering high quality work, for
staying true to the vision for the product, for communicating their schedule and
intentions, for making hard decisions, for delegating to others when they don't
have the time or skill to accomplish a task, for keeping team morale up, and for
No Fixed Bids
Some consulting relationships start with a requirements document or RFP
("Request For Proposal"). The requirements are often extremely detailed.
The probability of this document containing the optimum feature set is extremely
low. The right features are better learned through user interviews, prototyping,
releasing actual software, and getting feedback from real users.
Based on that document, clients expect consultants in the industry to submit an
exact timeframe and bid. This contract style sets the client and consultant
working against each other right from day one. Instead of focusing on designing
the product experience or evaluating what assumptions were wrong, they spend
time negotiating about what was meant in a document written a long time ago or
focusing on arbitrary deadlines. But it's worse than negotiating; it's
retroactively discussing something that no one remembers the same way.
As you might have guessed, we don't do fixed-bid, fixed-feature-set proposals.
We do need to know clients'
budgets. This is often
uncomfortable for them but their budget helps determines what scope is possible.
It saves time. If they don't know their budget, we discuss different options.
We talk about breaking product rollout into stages and try to improve the
product's chances of success at each stage by:
- Focusing on a small subset of features.
- Designing a valuable user experience.
- Developing a meaningful relationship with users.
- Budgeting for marketing tactics to tell users about the product.
- Designing interactions into the product for users to bring other users to the
We price projects at a per person, per week rate. We consult 4 days per week. We
use the same rate for designers and developers. The work required for each week
dictates which skills are needed. The number of people needed determines the
cost and how much gets done.
During the process of explaining our billing, we sometimes tell potential
clients "time and materials" is the same as hiring an employee for their annual
time except there's less risk to them because:
- Our team is experienced. We've interviewed more than a thousand candidates in
order to find the talented group of people we work with today.
- We've worked together on projects before. We have "a way" of doing things.
- Short projects require less money.
- Our time is predictable (4 days/week) and consistent.
- We can quickly rotate in a new team member if someone gets sick, leaves the
company, or is ready to rotate to a new project.
We don't provide itemized invoices to clients showing individual pieces of work
that were done. Clients always know what is happening via access to the project
management system (Trello), chat room (Slack), version control system
(GitHub), and ongoing communication with our teammates.
Examples of typical projects for us are:
- "Product design sprint", 2 people, 1 week
- "Idea to Version 1", 3 people, 8-12 weeks
- "Fill a gap until an internal team is hired", 2 people, 3 months
- "Staff augmentation with existing internal team", 3 people, 6 months
On many occasions we've done projects for clients who have a budget enough for a
"Version 1" product. They followed that up with a round of beta invites, time
spent learning in the market, a round of funding, or a few months of revenue.
They come back for another round of design and development with a more informed
sense of where the product needs to go.
The feature set of a product is not necessarily indicative of the length of time
required to develop it. Sometimes to get to a very simple product, we have to
iterate on it many times. We love working with clients who understand that a
great product takes as long as it takes.
In return, we understand that we can never abuse a client's trust in us. We
should be maximizing our productivity in order to provide them the most value
for our time. Things like our "Research" Trello board,
"Code" internal chat room, and shared
dotfiles ensure we have a highest
common denominator set of tools and techniques ready when the situation arises
We store contracts in Dropbox and have a series of folders for pending, current,
past, and lost clients.
The consulting proposal and contract contains:
- A one-page summary of the expected work.
- Our weekly rate.
- Net 15 payment terms.
- Payment for the first two weeks is required to start working.
- After the first two weeks, invoices will go out once a week on Saturday
mornings for the prior week's work.
- Agreement that the client owns the week's source code once they've paid their
- Agreement that both parties won't use materials which break someone else's
- Agreement that both parties won't publish things to the web hosting provider
which are abusive or unethical.
- Agreement that the contract is mutually "at-will" and either side can decide
to stop work at the end of a week.
- A page for signatures.
We use Quickbooks and Bill.com
to invoice our clients at the end of each week.
Clients can pay their invoice via check, ACH, or wire transfer.