Tweet This Post

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!

Tweet This Post

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!

Tweet This Post

Tweet This Post