Breakthrough on turning ideas into splash pages

I had an amazing day, yesterday. Met with another entrepreneur to work on a new project. For the first time in my life I was an active contributor on the creative side of the process. He had many creative ideas for this product which is geared toward the Indian matrimonial process. I was able to listen and synthesize graphic images to test the different ideas.

I cranked out logos, logos with gradients, different colors, sizes, letters kerned. Then we looked for imagery around Indian weddings. Grabbed examples and synthesized images to go on the splash screen. We ended up here:



Still not finished, but the experience of being able to finally work productively with graphical tools such as Photoshop and Fireworks was exquisite. The breakthrough book for me was, Layers: The Complete Guide to Photoshop's Most Powerful Feature .

I tried to take a chapter a day and work through the examples using the images he shows in the book. It is small (a great attribute in my opion) and instead of trying to describe every feature he sets out to build useful workflows for the majority of work.

It also requires some CSS knowledge to lay out the images on the page which I had built up over the last year. The feeling of cranking directly on what the user sees is great. Combine that with the ability to code the backend and test rapidly using splash screens, I think I am getting close to having a toolset for trying multiple ideas over the next year or so until I find one that sticks.

Managing queues can make a big difference for product creation

I read a book called The Principles of Product Development Flow. I do not recommend this book for the casual reader. It is filled with math and graphs, but the ideas are pretty interesting and very applicable to startup entrepreneurs.

My first question when I am reading about something new is, how can I apply this to give myself an advantage in whatever I am working on? So I called up a friend of mine that is working on delivering web sites to small and medium businesses.

I launched into the central idea: how long it takes you to get individual projects finished and out the door determines how quickly you see the economic benefits. The studies and math show that the closer you get to 100% utilization of each developer, the longer each item waits in that developer's queue being blocked by other projects.

When the project depends on different people, then queue size can really slow down getting anything finished. Unfinished work doesn't make you or anyone else money. In web startups many people are involved in developing a new idea or feature: creative art, layout, browser code, server code, and database work to name a few. If each person that needs to work on the idea is scheduled to be busy 100% of the time, then total time to finish any single project goes up dramatically.

The counter intuitive answer is to have more idle time. That way when the high priority work comes through it gets done immediately by each worker. Being busy all the time equals not having time to push through critical items in a timely manner. Also choosing wisely the work with the highest economic payoff or greatest risk reduction has a huge impact. The group has to understand this or they won't work on the most important projects leaving projects waiting.

Another key idea is what the author called cadence. This means if there is some part of the project that requires a group decision, having a regularly scheduled meeting that is automatic makes the overall progress faster, as you don't have to wait for everyone to schedule infrequent meetings. This sets a tempo for getting work done. Otherwise more features get crammed onto a release which things makes the release recede into the distance. This is also counter intuitive, as you would think regular meetings would slow down things. This is one reason daily releases can work, as they set a regular tempo for pushing out work.

So my friend and I started discussing these ideas. Immediately he started rethinking his business. He had been focused on having 100% of his hours booked. This led to lots of projects that are not totally finished, which means he can't get paid. Now he is approaching clients with a new proposition. Blocking off a definite time frame to start and finish the work for a better rate. He gets better cash flow and the client gets the project finished so they can realize the economic effect. He is even thinking of charging more if the client slows down the turnaround thus gumming up his project completion time.

He has been doing this for 2 weeks and starting to see happier clients who want to do more business with him and a fatter bank account. It is unusual when you find a book that seems written for huge companies and realize that it also applies at the startup scale.

How an engineer started learning more about design

I had someone ask me what path I have been following while learning design. Like any engineer I started by breaking down the problem into components so I could tackle them individually.

1.) Where to start: first problem was the classic chicken and egg issue of tool versus techniques. I didn't know any design / graphics tools because I wouldn't know what to do with them. Then I didn't bother learning any design principles because I couldn't implement anything without a tool.

2.) Tools: I decided to start with Adobe Fireworks / Photoshop. Feel free to substitute your own tool here. I read through a basic book on how to use these tools. I tried not to get too hung up on specifics, but focused on learning enough so that I didn't freeze when opening either of them up.

3.) Design Basics: a couple of books by Robin Williams (not the comedian): The Non-Designer's Design Book and Design Workshop. What is great about these books is that they focus on basics, such as, alignment and contrast. Just by becoming more conscious of 5 or 6 principles, I saw an immediate improvement in my work.

4.) Typography: The Designers Type Book (also by Robin Williams), Mac OS X Fonts, Mac is not a Typewriter. Again substitute an equivalent for the PC if that is your platform.

5.) Color: Guide to Communicating in Color and Color Design Workbook. These just explain basics about how color communicates with users.

6.) Layout with: Making and Breaking the Grid.

7.) Usability (which is different than design), such as, Designing Web Usability and Don't Make Me Think.

8.) Interfaces: Designing Interfaces and Designing Web Interfaces.

They key is to set a pace and not get discouraged. It is all about getting better than you currently are and developing a vocabulary so you can communicate with designers better. I know find that I have a much better idea of what the design process is and am less frustrated when working with top notch designers.

I've been solving the wrong problem

My background is industrial engineering. So I am constantly ask myself, "How can I do this better, faster, cheaper?" I have spent the last 2 years concentrating on how to build products faster and better.

At first, I focused on how to create basic functionality faster. I became very successful at quickly creating functionality that worked but looked terrible and probably didn't provide a very good user experience.

Then I realized building terrible looking products faster, wasn't working. Starting at the beginning of this year, I started focusing on design and usability. I'm not saying that I became a world-class designer, but learned the basic ideas behind design. It allowed me to move from a terrible designer to an average designer. Plus, I can now have a conversation with designers and be discriminating about what they tell me.

However, I then found myself creating better looking and more usable products faster that solved problems nobody seems to have. I still wasn't seeing results equal to the effort exerted.

I ran across Eric Ries talking about how 9 out of 10 new ideas fail and the tremendous waste of talent and effort in this undertaking. He takes his cue from personal experience and a book called: The Four Steps of the Epiphany, which I started reading.

The point he brings up is most ventures fail because they don't find a product that people want before they run out of money. Or worse yet, they prematurely scale up and early adopter sales won't support the company and they collapse.

My new approach is to start exploring how to efficiently discover what I should be building. I had the good fortune to have discovered a product that hit square on with what customers wanted: online dating. We were extremely efficient at building out and marketing, but never had to wander around discovering what people wanted.

So last week I experimented with testing a product pitch against Facebook traffic. It took only a day and $50 to find some customer data.

I am focusing on finding a set of tactics that allow fast, cheap evaluation of ideas. I am confident that if I find a product that customers want, I can build that product and scale it. Been there, done that. Now I need to learn how to find that product without going crazy.

Starting to work on how to iterate on products faster

After working on an idea with Cindy Alvarez at Startup 2.0, I realized that there is a dramatically easier way to test product ideas. So this week we brainstormed and came up with a new product idea for helping teachers track students progress in the classroom. Normally to test something like this I would have worked several weeks on creating a simple version of the idea and run customers through it to see their reaction.

Instead, I generated a splash page with our value proposition:



The button led to another page with a Wufoo survey:



Several aspects of the questions that Cindy used that weekend really resonated:

What do you think this product will do for you? It tests what the user thinks they are getting out of it.

The next question checks for who they think the competition is. Then a list of value propositions to find out what they think is most important to deliver in a product.

Then since we have an interested user, go ahead and try to recruit people for further beta testing of the product.

I made sure I had Google Analytics added to the site so I could see what happened when traffic got to the page.

I went on Facebook and ran a targeted ad that asked: Help your students. This got 63 teachers to the site. Of which 33% clicked the button to try the product. Then 11 actually took the time to fill out a survey for a product they now knew didn't exists.

From my experience with many products that haven't worked, this was a strong reaction to the value proposition as we communicated it.

We are not moving forward on this particular idea, due to a inability to visualize a monetization scheme that we believe is worth the development risk. But the exciting part was the speed and small amount of money spent on discovering consumer reaction to the idea. It was simple to target and attract potential customers, always a key consideration. Once the consumers saw the value proposition, we had a huge acceptance of the idea. All this for 2 days of brainstorming and $50 of advertising.

I am seeing a whole new way to start vetting ideas and testing them.

Starting to see progress from learning new technologies

I have started to see some results from my experiment to broaden out my technical skills. I started 6 weeks ago to tackle all the languages on the top 10 Open Source Project Activity List. It has been quite a slog, but in the last week the quality of my conversations with other entrepreneurs who are working on projects has changed.

Inevitably if you engage with someone who is already in the middle of starting up their idea, they will have picked a technology platform. Before this push on learning, if they hadn't chosen the technology stack that I knew (Ruby on Rails), then I had a very limited amount that I could offer in terms of concrete technical execution. At that point you are put in the same bucket as everyone else that is giving them advice, "Oh great, someone else giving me suggestions that add to my work load."

Last week, I starting talking with someone who is wanting to move their application to Google App Engine. This will require knowledge of either Python or Java. Now that I know the basics of Python, I am able to jump in and start looking at what that would entail. It is a great feeling.

Progress so far:
mastery: Ruby, Rails, Javascript, Dojo, CSS, MySQL
productive: none yet
literacy: Java, Python, C, Objective C, PHP, jQuery, Google App Engine
untouched: Perl, Django, Spring

This week, I am working on the iPhone stack with Objective C and leveraging Python on Google App Engine so I can move that one into the productive column.

My basic approach is still holding. I read a book and make flash cards, then as I exercise or find free time, review the cards. I rotate through existing stacks so that they stay fresh.

We will see. I won't know if this is a productive line of effort for another 3 months when more of the technologies move into the productive or mastery column.

Social Mobile Applications - what I see emerging

I have been going around for the last few weeks and looking at what people are working on and what seems to be getting traction. I have been describing it to friends as the social mobile revolution. People are taking older, successful ideas and asking themselves if there is a social or mobile aspect that would totally revolutionize how people use this product.

Can collecting data from people's phones that is geo-tagged make restaurant reviews better? One idea that won at Startup Weekend was FoodSpotter. It allows people to take photos of dishes that they enjoy at a restaurant with iPhone. This is then tagged by location and collected at a web site. Then you can use your phone to track down a dish rather than a restaurant. My wife understood the concept in 3 seconds and wanted to use it.

The common thread is that restaurant reviews have been around a long time. They serve a basic human need. However, almost every person now has a camera in their phone, and that camera knows (or soon will know) your location. This makes for an easier and more interesting version of the old product.

The second area is leveraging the social graph that sites like Facebook are creating. What would make restaurant reviews more interesting is knowing the opinions of people in your friendship network. Broadcasting out to your network or receiving from your network information about dining is more meaningful than a review by someone you don't know.

Again, it is taking a proven model and enhancing it with the two most exciting platforms to arrive in the last 3 or 4 years. I have been slow on the uptake but I am starting to see the new pattern. Now, I just have to find an area that hasn't already been staked out and turn over someone else's non-social, non-mobile apple cart.