Coder. Speaker. Writer.

On Saturday May 1, 2010, I will speaking on a panel entitled: “Taking Flight – Launching a Belief into a Brand” at the I Don’t Know to CEO: Transforming Passion into Action conference at the Annenburg Auditorium at Stanford University.

Tweet This Post

For the past three months, as a startup founder, I have been focused on customer development, creating a product roadmap, understanding the complexities of the industry of my product, and establishing a company culture.  This month in particular I’ve added another component to the mix: team dynamics. To me team dynamics goes beyond culture fit.  Culture fit is just a sliver, and is tantamount to does this candidate have a personality type that jives with the rest of the members of the team, and they’re willing to be collaborative, basically guaranteeing long-term harmony on the team.  Team dynamics are much more nuanced, and starts with each individual:

1. Understand the needs of each individual: what are their motivations, and goals both long-term (years) and short-term (day-to-day and months).
2. Analyze their aptitude: this is based on what they have demonstrated a proficiency in over the past several years, and what they are capable of doing.
3. Gauge their results: this comes down to giving them a small project, with clearly defined goals and parameters, and a predictable and measurable set of results.  Once you’ve done this walk away, don’t micromanage!

It’s not enough to do this once, you have to do it daily, weekly, and monthly.  The next step is to piece the team together.  Building a founding team comes down to the following:

1. Complementary skill sets – you want to make sure that people on the team aren’t stepping on each others toes.  Each founding team member should have ownership of what they are doing from the beginning and understand how they are interfacing with one another.  As the team grows owners might change and increase or initial members may want to move onto other projects, which is fine and to be expected.
2. Communication and comfort – as the founder it is your responsibility to let each member of the founding team know where you are going.  Even people in a startups crave stability, and one of the ways of giving them stability is by giving them a sense of where you are headed over the course of the next week and months.  Its also really important to attend to their most basic needs: food, water, and shelter.  You can’t expect people to work in a stressful environment without compensation!
3. Shared vision – before someone becomes an official member of your team you want to make sure they are vested into the direction of the company and share the same values and grand vision as you do.  This is a function of you as the founder executing on that mission, and if your direction does change, alert your team of that as soon as your decision is made, or involve them in the decision-making process.

My team is obviously very important to me, and I think about each person individually, and how they fit together.  The reason its important to go through this set of criteria and process is because the founding team you build translates to high performance in both good and bad times, the sort of people they will in turn attract to build out the company, and their decision-making process that will affect the course of your startup’s future and success.

Tweet This Post

I will be on a panel at the Invent Your Future Conference for Women, on Tuesday April 20, 2010 (10:15am – 11:45am).  The title of the panel is: Careers of the Future: Which One is Right for You?  The conference will be held at the Santa Clara Convention Center, Santa Clara, CA.

Tweet This Post

Design books are some of my most favorite and enlightening reads of all time like: Donald Norman’s DOET, John Maeda’s Laws of Simplicity, and Indi Young’s book Mental Models. They bridge together reason, emotion, and the physical faculties of humans in order to create tools to help people live everyday. As an engineer I have designed software for years, but until my most recent startup I haven’t had the opportunity to actually design the user facing component of a product. Here are some key principles to I’ve been practicing:

1. Learn empathy through personas.

I’ve come across a lot of engineers who just build stuff and expect people to “get it”. Thats fine if everyone were alike, but we’re individuals, who have different experiences, tastes, and ways of thinking and interacting. Think about the guy who just got laid off and now has to spend the next 2 hours researching health insurance, then fax in documents, make a few phone calls – be transferred multiple times – only to find out that he has to now wait two weeks for someone to “approve” of his medical records. What if he has a congenital disease and his prescription ran out the day he got laid off?

Yes, it’s an extreme case but stress does factor into the way humans interact with products and services, which is why its important to develop personas. A persona is an abstract representation of a set of behaviors. The persona’s name connotes her behavior e.g. “Jill” the receptionist at a yoga studio. Personas need to be developed for the primary group of individuals that will be using your product.

Immerse yourself in your user’s environment, and even better live a few days of their life.  You will retain the emotional response you had giving you more intuition when designing a solution to their problems.

2. Kill a tree.

I love building stuff and I hate wasting time.   Its important to build the right thing.  So instead of diving into coding up a web app, I created rough drafts of my product purely on paper, and then spent a month doing usability testing with over a handful of users in stages. At each stage I would iterate on the feedback I received from my users. Paper prototyping is a powerful process. I was able to gauge how users felt about my product versus the competition, what was missing from it, and what could be done to improve the experience of interacting with it. I also learned what users thought the most critical features was, which is essential to developing a prototype.

3. Shut up and listen.

Listen to the problems of your users. All of them!  An easy exercise to break the ice is to have a user walk you through their day, and have them highlight all their pain points. What was the latest catastrophe in their life? How did they solve it or try to solve it? From this you will learn how your users think, interact, and solve problems without you.  This has to be an ongoing dialogue because your users’ needs will change and they will keep having different experiences, so keep the channel open.  Expose problems over time, analyze them one at a time, and then create a bigger picture of their needs.

Tweet This Post

This is a follow-up to my prior post Pre-Launch Prep.  First, pat yourself on the back for making it through the launch!  Now let’s focus on next steps.  The product team’s job is to create and design features that will keep users engaged, and engineering team’s job is to make users happy.  Happiness == (bug free  && accurate data && responsive site).

1. Squash big bugs first!

Grep the logs and count the number of Exceptions or Errors then have it!  Best to create a nightly script to tally up Exceptions and Errors so that you don’t have to type the same grep command everyday.  You also want to check the user forums for discussions on bugs and talk to customer service representatives.  But before you begin doing a big fix make sure that the bug impacts a majority and not a vocal minority.

2. Get down and dirty with data.

Depending your product you might have data accuracy issues.  The easiest first step is to hit the production db and make sure the data that is being pulled in is correct.  If it is then you know there’s an issue farther upstream i.e. business logic or rendering.  If the db is wrong then you’ve got an issue with storing data, which could be caused by a broken link somewhere in the front to back-end flow.

3. Prioritize performance.

Everyone is always touting the vices of premature performance optimizations, which is a valid point, especially in a startup where you are resource and time constrained. You don’t need to optimize from the start, but you do want to build infrastructure to measure your site’s performance.  Performance is both a front and back-end issue.

• Front-End: your page load time is abominable because you’ve got lots of graphics that haven’t been sprited, have browser interoperability issues, or network latency sucks because your user bought the cheapest DSL package…
• Back-End: sure you’re using ajax on the front-end, but if each request is hitting the db and you’re pulling in thousands of records no point in being asynchronous…

Figure out where your bottlenecks are, and then tune it up!

Tweet This Post