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.
The BizeeBee team has been hard at work putting together our product. Our first addition is our blog The Hive. Please check it out!
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.
I’d been hearing a lot of buzz around jQuery and how much developers like it. While I myself am not a front-end developer and prefer doing mostly back-end work in Java or Rail, after I saw jQuery in action at SXSWi I wanted to learn to code it in first hand.
One of the reasons I never liked coding in JavaScript is because I didn’t like it being dynamically typed language and having to deal with retrieving DOM elements based on their names and the ability for the namespace to constantly change. I also found it cumbersome to have to deal with integrating CSS and JavaScript. jQuery resolves a lot of these issues for me. jQuery is basically a JavaScript library that lets developers manipulate DOM objects as if they were POJOs, and also manipulate objects based on their CSS classes. It also has an extensive animation library giving user a richer experience.
For those out there who are new to JavaScript I highly recommend the following sequence of tutorials:
And of course you need the requisite tools to get up and running so I’d recommend downloading the lates version of FireFox and installing the Firebug plugin to help with debugging any JavaScript issues you might have.
If you want to get further into jQuery check out the main site, which includes a testing framework QUnit,
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.
Figure out where your bottlenecks are, and then tune it up!
Being at the ground floor of a startup is the best, not that I’ve ever come in at a later stage, but having gone through the full lifecycle of one startup I can vouch for the beginning being the most exciting and romantic period. You define the product, engage with users, research technologies to use to build your product, and build the company culture. It can be daunting to take on all of these tasks, which is why it’s important to build momentum slowly. Reflecting on my experience at Mint.com I’ve realized that one of the key components to its success was momentum. The momentum that Aaron Patzer and the rest of use Minters kept building over time (time == 4 years, not the popular myth of 2).
There are a couple other companies that have had this natural progression as well: Twitter and Facebook. But I’ve also noticed more than a handful of companies that started around the same time as Mint and remained flat over the years or closed up shop because they couldn’t get traction or generate revenue.
How do you go about building momentum and keeping it up?
1. Start slow and understand the lay of the land.
As an entrepreneur and engineer it is very tempting to want to build something quick and fast. There is also a lot of talk of “failing fast”. If you expect to fail fast, what’s the fallback? You’ll figure it out as you go, right… Call me cautious but I believe in pipelining ideas especially when my own funds and time are at stake. To create a pipeline of ideas you have to understand the entire lay of the land. Take your initial idea peg it to an industry. Start by doing an in depth analysis of the major pain points in the industry, which means asking and answering the following questions:
It usually takes a couple a month or more to complete this market analysis phase, and its worth the effort because it makes you a lot more knowledge in terms of figuring out where you can add value and what the trade-offs are.
2. Put aside your engineering and entrepreneurial ego and learn to empathize.
Sure you’re a rock star coder, and you can get a web app running in no time, but coding at this point is a bad idea. Putting a web app in the hands of customers leads to more comments and questions like: “I don’t like this interface. Why is this button green? What’s with all the bugs?” And you’re left thinking these people don’t get it my product rocks! Or wow I wasted a lot of time writing code…
Instead you want to start having conversations with your customers. Talk to potential customers and walk them through the problem space you are exploring. Explore all their problems and then explore all their current solutions. Tell them you’ll come up with a solution on paper and would like to try it out on them. Unlike code the great thing about paper is that it’s 100% bug-free! The added roughness of a paper prototype forces the user to think in terms of workflow and interaction instead of the design aesthetic, which is much farther down the pipeline.
Finding customers who will be evangelical about your product – early adopters or influences – also helps with building momentum.
3. Create a product roadmap.
After talking to customers and getting feedback from paper prototyping you have to think like an engineer, which means making trade-offs. You are constrained by time, money, and resources (hands to code). You have to figure out how you can add value to customers given these constraints. Come up with a 1-3 year product roadmap that lists all the features and even includes a first phase revenue model. You might end up abandoning the roadmap entirely, but its purpose is to serve as a vision for your product and company. Use it as a reference when talking to potential customers, employees, and investors. That’s how you get initial engagement and continue to build momentum.
3. Measure Progress every week, month, and year.
Once you’ve launched it’s easy to get bogged down in the day-to-day affairs of running a startup: firefighting, interviewing, fixing bugs, handling user issues, etc. While these are all important tasks that have to be accomplished you have to be thinking big picture as well, which means measuring new traffic, user engagement, retention rates, and revenue vs. burn rate. To keep up the momentum you can’t solve each of these issues on your own. You have to broadcast these numbers to the rest of your team. The more you broadcast within your startup the more people think about solutions.
Post launch is where you can start to lose steam, because problems start to arise that were both expected and unexpected. You have to charge through it by prioritizing issues instead of solving all of them at once, and being happy with incremental progress. Focus on distribution (new users), engagement (keeping existing users), and revenue (making money off of all users).
4. Timing
Sometimes a series of events contributes to your success. When we started Mint.com the recession was looming, and figured it might make fundraising difficult, but it would also force people to become more aware of their finances. We got the best of both worlds: funding and frugality. The recession was a momentum booster, because it led to more press and coverage. You can’t bank on making bank this way. Instead, stay informed and learn to anticipate industry trends, events, the state of the union, and how they might affect your startup.
5. Don’t stop to smell the roses.
When you’re users tell you they love you its easy to want to bask in the glory of it. Enjoy the moment, literally. Then go find the haters, on-the-fencers, and non-believers and try your damnedest to convert all of them!
At the SXSWi conference this past week I attended a lot of great talks on iPhone applications that covered its user experience, development, and how to create apps that emulate the features of a native app but are quicker and easier to create.
User Experience
Josh Clark’s talk on creating apps that are “TapWorthy Applications” was one of the best talks I attended.
The following categories have successful iPhone applications because they focus on what the user wants to accomplish while “on-the-go”:
Each of these categories requires improving the quality of each tap by making it very useful for users. To do this you have to think about the basic functionality that users want that is divided into primary and recurring tasks. Simplifying the design requires focusing on the mobile context, what the user is trying to accomplish when micro-tasking, creating opportunities for exploring – secret panels and hidden doors to provide additional functionality without cluttering the design, and to think about ergonomics and industrial design so that it is easy to use the application itself. You will also want to condense the amount of data that is being presented to users, which Josh describes as the “glance test”, i.e. a lot of information can be gleaned by just glancing at the app. Apps that do this well incorporate large graphics and minimum amounts of data e.g. Weather App.
Finally prototyping on paper is a good way to figure out what it is users actually want and how they interact with the app before spending a lot of time building a code base for it.
Development
Jonathan Stark’s presentation focused on developing browser based mobile applications but still provide a lot of the richness of a native app. To accomplish this feat he suggests using the following tools and APIs: jQTouch, PhoneGap, CSS3 and HTML5.
jQTouch is a jQuery plug for developing mobile applications that emulate a lot of the functionality that a native iPhone app would have. The app loads in Safari but has a lot of the same characteristics that a native iPhone app would. The benefit is that it is a lot faster to develop and does not need to be approved by the App Store.
PhoneGap essentially fills in the gaps of taking a web-based application and transferring it to a mobile platform.
When I tell people I’m starting a company they somehow think I’m taking a huge risk. To me it’s the next logical move for my career. I could have gone back and finished the masters I quit three years ago, applied to B-school, or gone and worked at another startup or big company. But none of those options seemed romantic. At this point in my life I don’t have anything to lose, I don’t have any traditional obligations: kids, mortgage, or debt. I take care of my parents when they need me and I look out for my younger brother. I’m an exroverted loner who loves to work. Being an entrepreneur seems to be a logical and emotional fit more so than some huge risk. If I fail people will talk, but they already do…
Throughout the last 27 years of my life people have been telling me that I’m going to fail at whatever my current goal or ambition is. What’s funny is that this list includes the following people: my dad, boyfriends, teachers, coaches, professors, and bosses. Surprisingly this includes people who are supposed to be considered my “support- system”. Did they do it to be malicious or hurtful? Call me an optimist but my response is no. They were guiding me towards the safe path in life. They wanted to shelter me from the evils of the universe. I thanked them for their safety net, then proceeded to tear it apart.
I recently met up with a professor I hadn’t seen since I graduated from college and the first words out of his mouth were: “You haven’t aged a bit, and you still have a smile on our face.” The way I see it I have no cause for complaints. Here’s how I’ve learned to live the life I’ve dreamt of having as a child:
Focus is one of the keys to success. All-star athletes and entrepreneurs practice it day in and day out until the big win. It’s not just about keeping your eye on the prize, it’s setting goals and thinking about the execution of them and not letting anything distract you while you’re executing.
My senior year of high school I came up with a list of three goals I wanted to accomplish by the end of the year: be commencement speaker, win Texas State in debate, and get into Duke. My results: I got into Duke, got third place at the Texas State debate tournament, and didn’t make commencement speaker. I was pretty happy with 2 out of 3. When I got to Duke my junior year I decided I was going to switch into the engineering school and finish my EE degree in two years. I did.
How did I accomplish my goals? Well lets just say all I did was eat and breathe debate and college applications my senior year of high school. While my fellow Blue Devils were tenting, I spent my junior and senior year squatting in the engineering school’s basement.
I know it might not seem like much fun, but I loved every moment of those years, and being focused on something I’m passionate about is what keeps me going. The start of 2010 is another year of focus. As I get more involved with my own startup I realize that my days are spent prototyping, doing usability tests and talking to customers, brainstorming with my partner, and doing an ungodly amount of paperwork to keep the business running smoothly.
The following sounds tough and regimented, but its how I’ve learned to stay focused:
Finally, its easier to focus when you’re happy doing what you love, and by surrounding yourself with people who want to support you.
I will be speaking at the PairUp Conference April 8-9, 2010 in London; doing a pair presentation with Nick Pellant. The both of us will be speaking on how to go about starting a tech startup, and focused on inspiring the youth of the UK!
