Sales

We're designers and developers. We want to design and develop software. Before we can do that, we need clients to hire us. The following section details how our sales process works and answers commonly asked questions by potential clients.

The overall process is:

• Someone contacts us.
• We have them fill out our new project form (opens new window).
• We have a phone or video call.
• 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 (opens new window) and Google searches.

We track each lead in Freshsales.

We manually create Contacts for personal introductions. Our new project form (opens new window) automatically creates cards for each submission.

The designers and developers in the location will get notified about the incoming lead, but anyone can take responsibility it. The person responsible qualifies or disqualifies the lead, often with a quick intro email or phone call with the potential client. Before they move the lead forward in Freshsales, 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 (opens new window).

Roles

We offer some combination of designers, Ruby developers, iOS developers and Project Manager. An advisor assists the team for a few hours a week. Everyone is T-shaped (opens new window), 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 (opens new window), whose employees double as our outsourced operations team.

The developers also implement. They write and maintain HTML, CSS, JavaScript, Ruby, SQL, and lots of other code. They set and meet development standards, keep the Continuous Integration (opens new window) build 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. The rest of the team does not report to them. The advisor is also not a technical or design lead. Advisors need not be Managing Directors or CXOs, but typically are due to flexibility in schedule. Anyone at CodeCarrot should be able to advise a project. If the primary salesperson is not also the advisor, there should be a smooth hand-off from one to the other.

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 being consistent.

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 (opens new window). 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 (5 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 (Sprints), chat room (Flock), version control system (GitHub), and ongoing communication with our teammates.

Typical Projects

Examples of typical projects for us are:

• "Product design sprint" (opens new window), 2 people, 1 week
• "Zero to Version 1", 2 people, 4 weeks
• "Fill a gap until an internal team is hired", 2 people, 3 months
• "Staff augmentation with existing internal team", 3 people, 6 months
• "Maintenance team" (opens new window), retainer per month

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 and "Code" internal chat room, and shared dotfiles (opens new window) ensure we have a highest common denominator set of tools and techniques ready when the situation arises again.

Contract

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/Project based rate.
• Net 15 (opens new window) payment terms.
• Payment of the first two week or 20% of the total outstanding bill 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 Clockify to invoice our clients at the end of each week.

It sends recurring invoices so we don't forget to bill people at the end of the week. It automatically sends late payment notifications, limiting awkward conversations about the bill.

Clients can pay their invoice via check or wire transfer.