Lean design for entrepreneurship

I was reading about and watching some Youtube videos about lean entrepreneurship. The ideas that were in there are not much different from what you encounter in some of the conversations about agile and lean software development. With each of these things there seems to be something missing. Because the whole idea of lean is that you start with an idea and you create multiple prototypes. You learn from the prototypes and then you keep building.
The problem I have with this process is: how do you know if the idea you begin with is the correct idea?

It seems to me that is an awfully costly endeavor to go and build a prototype on the wrong idea when there are many cheap and efficient ways to find a better idea. Industrial design and inventors, for hundreds of years, have been doing different ways of generating and narrowing down ideas.Typically design uses the concept of going through sketches and small prototypes, comparing those sketches to each other to see what works and what doesn’t work in each of the sketches.Narrowing it down to those that you want to prototype and then you build from there.

You should be able to create different levels of prototypes. Lo-fidelity prototypes is the term used in design. These prototypes maybe on paper, blocks of wood, clay or a simulation. With these prototypes, you can create them and bring in front of a potential users and get feedback without a huge amount of costs and time in order to do it. This process reduces costs and and time involved in order to test the solutions put forth.

The process of lean entrepreneurship would be much more efficient and much more cost-effective if sketching and lo-fidelity prototypes were used in order to get to what lean refers to as a “pivot.” You should be able to pivot before you build.You don’t need to pivot as you build it. Pivot earlier and quicker in the product creation. Weed through the ideas that do not work before building working products. This will reduce the number of product pivots when you’re building your business model or your delivery mechanism.

You’re going to want to iterate on your solution in order to hone it for the users you want to go after. But you should be able to figure out how to prototype and to go through different solutions in the space in order to pick the best ones.

For most aspects of human performance when you measure and plot out the population of different things that humans can do, whether it be how quickly they can type or what are the best ideas they can come up with, if you plot them they would plot on a normal curve. If the plot is on a normal curve that means that the center of the curve is where most people reside. So if you pick an idea, how do you know whether or not your idea is sitting to to the left of middle or that your idea is not the worst idea. At this point, you are going to take this idea and start doing lean development so that you can slowly find out that your idea is not the correct idea.

If you follow design methodology, you should be able to go in and play the numbers game early. I have to imagine as an investor, if you’re investing in different companies the reason why you invest in many companies is because you want a better opportunity for success. You are hoping that somewhere along the line that one of the companies in your portfolio has success and has a lot of success. What you do is go through many different companies and many different ideas.

With sites like Mass Challenge and these places where they have people focus for a three-month period, they have hundreds of people and they compete against each other. Hopefully in the in the end your contest winners end up being the successful companies. You watch them compete, you watch them succeed or fail at whatever they were trying to to do. You want them to succeed early and quickly with little investment put into it.

If that is the case, then why would you build first to see whether or not your idea works? Why don’t you go through the process of sketching, ideation and storyboarding? Go from story-boarding through prototyping. You should be able to go from hundreds, if not thousands of ideas, narrowing it down to to tens of ideas that you would storyboard out from beginning to end. Then you should be able to take the storyboards and test them and narrow it down to three ideas that you want to to prototype.

During this process you should be validating each storyboard and design with your potential users. You should be able to go and engage them and find out whether or not your ideas even work for them. You should be able to narrow down to your three ideas that you think have legs.

In order to move forward, now you go through the lean process. Now you go in and start developing these 3 ideas rapidly. Pick your minimal viable portion of the solution. You put it out there and get the people that you have involved using it. See how much traction you get on each. You should be able to run your comparison between these three different ideas in order to get statistics and numbers back. Use these numbers in order to understand where you go.

Overall the the lean process makes sense but it will make more sense when you’re in the development phase. It doesn’t make sense when you’re trying to decide which idea and which solution is the best solution to work with. Lean starts off with an idea and or a variation on an idea, tests the two of them, and then iterates upon it it. You have to assume then that your idea is the best idea in order to begin. If you are an average human being, like most people are, then you will create average ideas and you need to work out the kinks before you bother starting your development. So create many ideas, sketch them, storyboard them, keep on comparing them, narrow them down, bring it down to 2 or 3 ideas that are the best ideas. After you compared and contrasted all the ideas and storyboards that you have, select the best ideas and start your lean process.


Cyclical nature of design in a software company

How do you handle the cyclical nature of design in your company? Every software company I have been in, the design projects are like a snake swallowing its food whole. One big project pushes through and then you just have to wait for it to digest.

The projects come in the beginning of whatever cycle engineering has whether it be 6mos, a month or 2 week sprints. Everyone wants some design but not everyone is ready. One team is ready and a big push is made. Research, analysis and design are done simultaneously as the team starts up again. Everyone is learning, everyone is ramping up and the push for the designs is made.

Taking on one, two or maybe three teams at a time is about all that one person can take on and do a good job. After the design is put forth work is needed to make production versions of the features developers are going to work on.

So the work shifts between user analysis and visioning, product analysis and simplification and inline production work. Visioning and simplification are intensive design efforts in short bursts and the inline productions are routinized and drawn out. Since engineering tends to be the larger and schedule driven part of the organization, all the design work is done in their cycles. Most companies I have worked for align all their development teams on the same cycles so you get peaks and valleys.

Would companies hire a design partner that trains and staffs themselves with designers? A design partner that creates a deep bench that can meet the peaks and lows as needed. Create a permanent relationship as if we were your only designers however we keep the designers fresh, interested and invested by constantly providing the feast and scheduling around the quiet times.

Communication Tools at Work

Email still is the main tool for communication at work. Even with all the ports of social media to the enterprise, email is the core tool.

The are several problems with email that people are trying to solve with social media such as the asynchronous aspect of email and the heavy client on the machine as well as the coolness factor.

However, social media and email for that matter have the wrong object of communication. In the social media world the communication itself is the object. In the business world the “work” is the object of communication. We are not at work to chat with each other. We are there to get stuff done and we use all these things to communicate around the work.

Email has the problem that it is associated with the person not the work. If I were to design email from the ground up then I would focus it around the work unit.

The communication should be associated with the work unit, the PPT, web page, Photoshop file or whatever else you are working on. The communication should be stored in relationship with the work unit not with the person doing/receiving the communication.

Objects of work are usually associated or organized by projects and have a team of people associated. The communication needs to incorporate the team and all the project’s work objects.

How can we design a communication tool that is associated with the context of the work you are doing?