Growth is fun and exciting in a startup, but it can also be just a little painful and scary.

Its scary because people can’t anticipate problems that arise from growth such as having customers, supporting them, answering their requests, and fixing the issues they experience with your product.  Or adding employees, training them, educating them on the vision of the company, keeping them motivated and collaborating with each other.  And then there’s the product itself!  More customers are using it, and generating data which leads to a less than awesome experience for your customers.

This isn’t the time to feel overwhelmed.  Its the time to pat yourself on the back: you found product market fit and you’ve recruited some stellar people to help you out!

Now you’ll need to change some processes to handle the growth which can be the painful part.  Its easy to throw money at the problem, but lets just say you you may or may not have access to a seemingly bottomless pit of cash.

Figure out what you need not what you want.

It all comes back to milestones.  Where do you want to be in 3 months, 6 months, and 1 year?  You don’t need to have definitive growth numbers for your startup but you need to put things in perspective.  Lets say you’re shopping around for a customer support ticketing system, and right now your growth is fairly predictable and manageable by a single human being and possibly part time.  In that case don’t buy something that’s going to cost more than what a single customer is paying you monthly.  You might even be fine  doing support via email and phone, and it will probably aid in your customer development process to have someone listening for feedback.  If your customer support person starts to get inundated then its the time to look into a system to organized.

Start shopping for products when you want to cut down on human labor costs that are quantifiable by time and money.  The people you hire are smart, so invest in their productivity and happiness, and don’t let them become drones by having them do repetitive mundane tasks that aren’t advancing themselves or the company.

Building vs. buying?

You’ve isolated a few areas in which you need to put a new tool in place or replace an old one.  As engineers running a company its easy to say: “Oh I’ll just build it!”  Wrong answer.  Yes it might be super easy for you to whip something up, but who’s going to test that new tool, maintain the code base, and add on to it?  If its you great!  You now have a new department: internal tools.  Oh you’re small… well then you just cut down on product development.

Save yourself some keystrokes and shop around for products instead.  As I mentioned before, if you identified your needs then it becomes easier to tell people what you want and to shop around for it.  Yes there are times when you might not find what you’re looking for, and it might make sense to build it in house if its cost effective (cost == time + money).  If you find a product that satisfies 70-80% of your needs and is within your budget buy it!

When I was working at Mint I had the painful task of searching for an email provider to handle all the outbound emails we were sending.  Integration was a nightmare especially given the products that were in the market at the time.  Had I taken a little more time to do research I would have found MailChimp and been happier.  Live and learn.

Fortunately I did learn, a different lesson while working there, put off managed hosting for as long as possible.  Which is why  when I started BizeeBee I went with Heroku.  Could I have written deploy scripts, and the add-ons that they offer on my own?  Sure, in fact I wrote some of them at Mint (sms and email messaging, performance monitoring, etc) in Java!  But going with a solution like Heroku for less than $100 a month gave me the freedom to build, iterate, and launch BizeeBee all in the same year!  Did I mention $100 is also less than the going rate of a developer pretty much anywhere.

How long will the solution last?

Remember the title of this article is retooling.  If your startup is on a growth trajectory it will outgrow tools, and you’ll need to refine processes.  Get comfortable with it.  They key is to identify when you’ve outgrown a product or anticipate when you will.

Sometimes you can live with a less than perfect solution for awhile, especially if its cheaper than the alternative in terms of setup and maintenance.  Just acknowledge the limitations, and prepare to fix them if they cut into progress.  For example, at BizeeBee we have a customer support tool that I built.  Its not perfect,  it drags the system down a little when we run large queries, but we’re operating with limited resources.  I’ve optimized the queries once they really start to impact application performance, but I haven’t yet setup a dedicated database, and optimized the heck out of it, because I have other priorities.  I’ll throw resources at it when it start to cost us customers and time, or isn’t serving its purpose.

ROI

Retooling is not a cost.  Its a cost if you do it prematurely.  If you do it when you absolutely need to or when you anticipate a need arising then it can actually be aid in the growth of the company.  Once again figure out what you need.  Do you need to grow your user base?  Do you need to keep your customer happy?  Do you need to get paid on time?  Do you need your employees to be happy and productive?  Those should translate to what you’re looking for in a solution.

Retooling isn’t just about finding the right tool, its also about finding the tool that will help you you meet your next milestones, and once you reach them you’ll need to retool again.  Happy retooling!

Despite being a code loving femgineer I secretly harbor a prediliction for design and focus on user experience, which is why I read books like John Maeda’s The Laws of Simplicity, Donald Norman’s Design of Everyday Things, design infographics (What its like to be a Yoga Instructor  in the US?, What does it cost to pursue your passion?, Studio Stats), and am obsessed with prototyping.   I think its just my innate desire to be creative.  For those who are like me or want to learn more about the user experience I thought I’d share this infographic I recently came across done by Onward Search.

In 4 days it will be the 1 year anniversary of launching BizeeBee my second startup. When I started BizeeBee I was determined to put in place engineering principles that I hadn’t been able to at previous companies.  I also wanted to avoid a lot of bad practices that I had experienced throughout my career such as splitting the responsibilities of development and testing, and product bloat.

I know most startups like to take the quick and dirty approach to product development, and then go back and refactor or rebuild their product.  I think that’s great and we’ve certainly refactored a lot of our code base too.  But I started charging customers from day 1 of launching and had to convey confidence to get them to pay.  So I emphasized quality first and foremost.

My vision for BizeeBee’s product and engineering team was to create a simple and high quality product, and to do so cost-effectively.  I communicated these constraints to my team, and we knew there would of course be trade-offs, but we all agreed to these basic principles to guide our decision making and product development process.

Invest time in talent

In any industry employees are not interchangeable.  I know there are a lot of people who like outsourcing and just want something “built”.  This is fine if you are driving a culture of results.  But I truly believe employees need to be engaged in worthwhile work to produce quality.  So I hire for raw talent, hunger, and patience above all else.  I truly believe this is the only way to attract top performers.  You can look at people’s track record, but many don’t have one, so you just have to rest on raw talent and motivation.

Having a talented team is great because it means they will invest time in learning, after all talent is just a byproduct of learning, practice, and refining a skill.

So I invested the time in letting my engineers learn Rails and the entire stack of technologies that went with it.  I also had them talk to experts in the field about engineering process.  We adopted an Agile process and pair program.

Trade-off: giving people time to learn and not spend all their time developing means that less features will be built.  I know most founders would be too impatient with this approach, but I guess that’s why its helpful that I do yoga

Cost Effective Quality

I didn’t have the luxury of having enough money to hire QA engineers, but then again I never liked how engineers would abdicate responsibility for their code to someone else.  Not having a QA team meant that my engineers would need to test their own code.  So for the first time ever I got what I had wanted: TDD (test driven development).

Trade-off: once again less features are built, but what is built has a high level of quality.

Simple Design & Integrating Solutions

Over the course of my engineering career I’ve read a ton of design books, because my personal mission of becoming an engineer was to build things that improve human life.  So I wanted to build products that had an emotional appeal, and people would derive joy and want to use them all the time.  Life is already full of stress, the last thing I want to do is cause someone to have a bad day because I built a shitty product.

We don’t build everything, especially if we can find a good off the shelf solution.  If we don’t find one we’ll either build it ourselves, and if its not cost-effective then we’ll wait until we can afford to build it.  This of course means we’re spending a lot of time doing research, talking to vendors, understanding terms of service, and understanding the long terms implications of the partnership.

Trade-offs: this can stall product development but its important to know who you’re getting hitched to

I can’t speak for other startup founders but as one who wears both the business and technical hat I’ve had the freedom to create a company and engineering culture that I’ve grown to love and can be proud of.  I have to give a LOT of credit to my two developers: Alex Notov and David Grieser who pushed me into implementing a lot of processes and have made me a much better femgineer.  I also want to thank Jesse Taggert for her help with product design, and introducing us to Kevin Fitzpatrick at  Pivotal Labs.  And last but not least Lyndi Thompson our buzz bee who spreads the word about our product and team, and keeps encouraging me to write code and blog posts.

Its been a good year and I look forward to continuing to build BizeeBee in 2012!

I’ve gotten some requests recently to write a post on how we’ve gotten early adopters at my startup BizeeBee and how we got them at Mint.  I hate to burst everyone’s tech bubble but there is no secret for getting early adopters.  I also want to address two concepts in this posts getting early adopters vs. methods for customer acquisition.  The reason for the dichotomy is that an early adopter is essentially a product tester and product evangelist.  They will stick around forever and are highly critical to the success of your business because they promote your product, but to me they are not really customers.  Why?  Because early adopters are people whom you get by talking to them directly and they help you build out the alpha/beta versions of your product. They’re loyal, and will give you lots of feedback. Customers are the people you pay to acquire through advertising, struggle trying to keep engaged, churn through, and whom early adopters get to buy your product through word of mouth marketing.

Why do you want early adopters? And how to do you get early adopters?

Because early adopters actually prove product/market fit.  Your early adopters are the folks who are going to use your product, give you honest feedback, and will wade through bugs and various iterations.

First you need to figure out who you’re trying to solve a problem for by creating a persona.  Then you need to get out, show them your prototype (preferably one that is paper-based), and then ask them to try out the actual prototype.  Drop-off point #1, people  are busy…  You’ll get a lot of “sure contact me when it’s ready” or “send me access to a demo”.   In reality you need to talk to a lot of folks before you can even get one to respond, play with the product, and give you feedback, which by the way is the whole point of getting early adopters!

The key to getting more early adopters is to think like one.  Figure out where these folks hang out (online and offline), what they read, where they learn about products, and who they learn about products from.  Then go out and talk your product up in these channels.  What you’ll most likely hear is what we heard at BizeeBee a bunch of: “No, we’re not interested.”  So we changed our approach, instead of trying to sell the product to people we started asking “Why don’t you like our product?  Who do you think would be interested in trying this out?” And that’s when things got interesting…

We got some “Well I know this guy in New Orleans who just opened a small studio…” and a “Oh my studio is too big, but our second studio is relatively small…”

Now of course we get “Well I really need this for my vertical, when is it going to be out?” Hook, line, and sinker

The final point I’ll make about early adopters is that they’re great for testing out the product’s concept, workflows, and positioning in the market.

And now the challenge begins…

How do you get customers?

When I first moved to the Bay Area in 2004 I’d heard buzz words like social and viral, because Facebook was dominating the market in terms of growth and there were social networks galore.  Now 7 years later I hear countless stories from startups who basically talk about how they hustled by iterating on the product, and finding the right customer base to target until they saw traction like Airbnb and Square.

At Mint we acquired customers through a combination of AdWords, InfoGraphics, and PR in print (blogs, magazines, newspapers, etc.).  PR was the most significant channel but also the most expensive approach, so I don’t know if I’d advocate it for every early stage startup.

What’s more interesting is the approach we took and how we explored various channels, measured the results, measured engagement, and then looked to see a correlation between engagement and monetization.  IMHO you don’t really have a customer until you monetize off of them.

We monetized off of lead gen, which is one tactic amongst a wide array.  The good news is that unlike the early to mid-2000s when everyone was giving away their product in hopes of  making money off of advertising and users were use to everything being free, nowadays users are willing to pay for things on the interwebs, but only for things they absolutely can’t live without…

Acquire first, monetize second?

Call me a capitalist but I’m not sure when the concept of going into business to give stuff away became the norm.  Yes I think you should pay to acquire a customer, that is of course the point of advertising and marketing, but this phenomenon of essentially giving away your product for free in hopes of luring a bunch of users, getting them hooked on the product, and then charging them seems silly to me.  That’s got to be the fastest way to make a hockey stick graph flip 180 degrees on its x-axis…  Even in a platform play there’s going to be a level of engagement (as in click throughs and conversions).   So what’s the point of having a 100k users if you can only monetize off of 1k or worse 1 of them?  You can of course build a cool product to sell it to someone else, in which case that should be your monetization scheme, i.e. exit strategy.

So to summarize:

• Get some early adopters to fall in love, play with your product, and give you constant feedback.
• Getting customers is going to be a bit of a shotgun approach, but measure each channel, and test which ones convert to paying.  Be quick about this unless your gut tells you that some channels take longer than others.
• If you’re going to give something away for free you need to make up the cost of building it somewhere else.

Remember this is a hard process and it takes time.  But it gets easier if you create feedback loops, listen to what your early adopters and customers are telling you.  If the product sucks fix it, if the pricing is confusing make it clearer, if marketing is expensive look for less expensive channels, and if you aren’t building something that people want then figure out what they do want and build that!

Its been 8 months since we launched our first product at BizeeBee.  When we launched we had 3 customers (yoga studios), they saw the value in what we were building, so much that one studio owner  worked very closely with me for almost year.  Since launching my desire to please customers hasn’t stopped.  The buzz bee and I spend nearly every week talking to customers either on Twitter, Facebook, via email, or on the phone.  I’m always asking for feedback on the product, improving how we react to bugs, and listening to their problems.  Why am I so obsessed with talking to customers?  And why do I care about their business?  Because no one on my team including myself has ever owned or managed a yoga studio!  I’ve worked behind the front desk, and seen how they operate, but I myself have never owned one.  Since none of us have lived the life of a studio owner and we’re designing a product for them, we have to learn to think like them.  Here’s how to cultivate the learning and get your team to understand who you’re building a product for:

1. Develop personas

Sure some would say this is easier said than done because at an early stage the customer is constantly evolving.  But if you’ve gotten some level of product/market fit you should have customers that are using your product everyday, or have some predictable rate of use.  Fortunately for us we have a core group that is using the product everyday, and I know this because I log into the admin I’ve built everyday to see what people are doing.  But here’s the next part that is hard for startup folks to do… pick up the phone and give customers a call.  Yes I know they’re busy, you’re busy, everyone is freakin’ bizee. But I’ve learned more about the nuanced ways in which people use our product by listening to them on the phone or watching them in person.  The other great thing is that once you’ve got them on the call you can learn more about their needs. Its finding out the needs that’s the key to developing personas.

To me a persona is a set of personality traits and problems that a person faces.  We currently have 3 personas that our product works well for, meaning they adopt our product and are relatively happy.  I know those who don’t fit the persona will drop off, and that’s fine too.  Here’s what I do with the persona:

• I convey it to my team so they develop empathy.  Its that empathy that lets them design and build a product that actually meets the needs of the persona.
• I use it when talking to potential customers.  When someone calls us, I ask them some pretty basic questions to see if they’re a match.  If they are I try to sell to them, if not I tell them they’d be happy with one of our competitors.
• I put the personas in ALL of our marketing materials.  I want the world to know who BizeeBee is for and who it isn’t for so that I get a match.

2. Build a Community Brand So You Know What to Build

I’ve always had an issue with the vocal minority and using anecdotes to build features, to avoid it even being an issue I actually took sometime to create a customer feedback forum.  Our customers can post bugs, ideas, and vote up  features.  We use the forum as a guide for what gets built.  There have been a couple times when I have literally dropped everything to build a feature because I saw how popular it was and I was tired of losing leads.

I know there are a lot of founders out there who take a “father know’s best approach” to product development.  That works too.  The reason I chose the community route is because I saw that the people we’re catering to weren’t being heard by our competitors!  The other is that people who have a voice that is being heard are willing to contribute their ideas to improve the product and tell other potential customers about it!

Now the one caveat I will mention is that what gets built still needs to match the main persona.  And this is important, because then your team begins to understand the reason why they are building or refining one feature as opposed to another.

3. Let Ideas Simmer

One of the interesting things I’ve learned about the bees is that on average it has taken each one about 3 months to get into their groove.  By groove I mean building, selling, and communicating with one another.  As a founder you cannot rush this process.  I know it can be painful for them, but watching them go through the process and coaching them through it has actually been really rewarding for me as a founder.  People need time to absorb the vision, adjust to their environment, and let the ideas simmer before they really feel like they get what it is they are working on.  There will be moments of confusion and clarity.  What helps bring clarity is having your teammates talk to customers, read customer emails, and understand the dichotomy of who is and isn’t a customer and why (once again refer to #1).  There will also be a lot of “Why don’t we go after this new group?  Why did so-and-so not convert to a paying customer?”  Instead of answering these questions yourself have the last hire explain the answers.  You’ll be surprised by the results

So why is it so important that your team understands your customer, why not just have them shut up and build?  I’m no genius nor am I capable of coming up with solutions to every problem.  I’ll admit I need help selling, building, and running a company.  The more I communicate with my team the more they know what’s going on, and in turn can make educated decisions.  Having direct interactions with customers is even more powerful because part of the reward of being in an early stage startup is seeing that what you build actually matters to people and improves their lives, that’s the greatest motivating factor of all!

Today I woke up to find this email in my inbox:

I just wanted to thank you for your time on Friday.  It really was a perfect time for us to be hearing your advice.  Some of the questions you asked about marketing touched off some incredibly productive conversations this weekend… not only about our marketing strategy but more importantly, our company strategy.  Here’s to newfound focus!

Basically a startup founder was thanking for me for spending about an hour and a half of my time consulting for them on marketing strategies that would take their product and company to the next level.

The founders were great guys who are really ambitious but know their own limitations when it comes to marketing.  Having me come in as an outsider was a great exercise for them because I brought in a fresh perspective to some problems that the were experiencing and gave a few suggestions and ways to think about marketing their product.

Too many startups can get trapped in their own downward spiral in a variety of areas: hiring, marketing, product development, brainstorming, engineering issues, etc.  What I’ve found immensely valuable is to talk about it within your own team, but then to also solicit feedback and solutions from people on the outside.

Here’s the approach I take when I consult or give advice:

1. Understand the company and product history

You need to dig in and see where the company started, what they’ve accomplished, and where they’re headed next.  The other is to also understand what strategies they’ve already tried out and perhaps do a quick postmortem on why those strategies succeeded or failed.  Sometimes just running through a postmortem gets the team thinking of different approaches.

2. Don’t tell people what to do, give them a principle

This goes back to the old adage of “teaching a man to fish”.   I give startups some basic principles or tools that will help them out.  For example, the startup that I was consulting for wanted to know how to write better blog posts.  I took a step back and asked them what the position of their company was and what problem they are trying to solve for their users.  Going through that process helped them understand what the mission of the company is and how that can translate to conveying that message to their users.  Their blog posts should focus on the major problems their users are experiencing and solutions to those problems rather that just pushing product and feature how-to’s.  The posts can provide solutions that come from the startup’s products, but most of the time its worthwhile to write posts that provide free advice to problems so that users know anytime they experience a problem in a particular area they can come back and read the startup’s blog for suggestions.

Instead of telling the founders what to write, I helped the startup understand that blogging is just a way of positioning their company i.e. controlling the messages and perception users have of their company, and how they can find their unique voice.

3. Focus on small changes

You don’t want to overwhelm people with advice and tackle every single problem.  Yes its true startups have many problems, but the point is to focus and prioritize.  Pick one problem area and spend time brainstorming just that.  Often times picking one will expose errors in judgment, process, and execution that the team will then realize and start applying to other problems, and that goes back to #2.

Advisee’s Role

Don’t just take whatever advice people throw at you.  You want understand the context that its coming from.  Be open to  it and  don’t take suggestions as a personal affront.  Also make sure it fits in with your startup’s culture and timeline.  Your role as the advisee is to evaluate the advice and apply it when and where you think its appropriate.

My recent blog post for Seattle 2.0: Major bug or vocal minority?  How to Use Feedback from Product Users.  The post covers how to think and evaluate bugs and features in the context of  pleasing users.  I’ll also be speaking at Deploy 2010, hosted by Seattle 2.0.