Business Development

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 meet in person.
• 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.

Leads

Our leads often come from referrals from clients and Google searches.

We track each lead in Freshsales.

We manually create Contacts for personal introductions. Our new project form automatically creates leads for each submission.

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.

NDAs

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 NDA.

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.

Budget

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 product.

Rate

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.

Typical Projects

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 into new tools and processes, guides, and shared dotfiles ensure we have a highest common denominator set of tools and techniques ready when the situation arises again.

Contract

We store contracts in Google Drive 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 weekly invoice.
• Agreement that both parties won't use materials which break someone else's copyright.
• 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.

Invoices

We use Quickbooks and BILL to invoice our clients at the end of each week.

Clients can pay their invoice via check, ACH, or wire transfer.