How I Started a Company in 72 Hours

Recently, I helped found a company with 3-Day Startup. 3-Day Startup (3DS) is a program that assists college students (and current professionals) with creating a new company over the course of a weekend. We did everything from idea selection, market validation, prototyping, and a final pitch to a panel of investors and entrepreneurs. Naturally, three months of work (the first iteration) were compressed into three days.

a PVC pipe and tea bag

The first prototype of our shower adapter and scented pod.

I joined the team known as “Herbal Fresh,” which aimed to produce a device that infuses shower water with scented herbs. I had little faith in Herbal Fresh at first–we didn’t function as a team the first night. We were nine students majoring in fields from advertising to computer science, and we knew little about how to create a new product. How would we get through the entire weekend?

The next day was fresh start. The mentors at 3-day Startup taught us how to interview potential customers and determine if our initial assumptions were true or not. So the Herbal Fresh team took to the city of Austin to see if anyone was having the problems we were trying to solve. We found our customer archetype: a busy woman in her 20’s or 30’s that shops at Whole Foods and likes to do yoga.

With our market validation, we tweaked our idea and began to prepare a slide deck for the pitch. Since I had seen dozens of pitches in the past six months, I helped create the deck and advise the presenters. My team members called me the “coach” of the group, a title I was happy to hold. However, the first practice presentation was approaching rapidly, and there was little time to rehearse.

All the teams filed into the presentation room. Herbal Fresh was two members short. Where were they? Suddenly, our two engineers burst in with a working prototype a minute before we were scheduled to present. It was a crude device made of PVC pipe, but the entire team erupted with excitement when we saw it. No one in the room expected to have more than a sketch or a mock-up. It was a tiny achievement yet overwhelmingly amazing.

Our working shower fixture

The shower adapter infuses the herbs and fragrances into the shower water.

The next day was full of accomplishments. One member removed two shower heads from his apartment for a better display of our minimum viable product. In addition, our advertising major created an astonishing slide template and pretty bags of real herbs for the panel. But most surprisingly, while I was coaching our presenters through the pitch, the two web developers built a website which allowed potential customers to sign up for a mailing list. By the end of the last day, we were ready to present.

Our presentation went perfectly. Though we were not without criticism, our idea seemed on-track for potential monetization. Despite the frustration and disappointment of the first night, we ended the weekend with the feeling of success. Further iteration on Herbal Fresh looks likely–we will probably refine the prototype and seek further market validation.

Just a few days prior, I thought herbal showers were a doomed idea. I was wrong. There are tons of problems to solve (and assumptions to prove), but I think the concept has real potential. Herbal Fresh might crash and burn, but if we do, we’ll crash quickly.

For more on student startups in Austin, check out Longhorn Startup Demo Day and Echoed.

Posted in Startup, Startup Spotlight | Tagged , | 1 Comment

How We (Unintentionally) Manipulate Our Friends – Part 3

In my last few posts, I’ve discussed how people tend to state their opinions as if they are facts, and at other times, state their opinions as demands. Today, I’ll discuss the least-often used method: opinions as preferences.

Stating opinions as preferences occurs when the speaker uses a phrase such as “I think,” “I prefer,” or “I would like.” Take these statements, for example:

  • “I think that riding roller coasters is fun.”
  • “I prefer that everyone visit Bob’s Car Wash.”
  • “I would like you to finish the project soon.”

Stating opinions as preferences is the least used way of stating opinions, but it is the only way that implies equality between the conversation’s participants. The speaker comes across as more humble and allows for a less confrontational discussion. Of course, the speaker’s body language, tone of voice, and word choice can still create a hostile atmosphere (just as nonverbal cues can create a friendly atmosphere even when opinions are stated as is if they are facts or as demands).

Still, stating opinions as preferences is good for establishing a sense of equality between two parties. This also is more likely to induce compromise and establish trust, unlike tricking the listener by stating opinions as if they are facts. The other alternative, stating opinions as demands, implies the listener will be punished for disobeying the speaker’s commands.

Which method do you like to use in conversation with your friends and family? And which method would you like to hear used more often?

Posted in Psychology | Tagged | Leave a comment

How We (Unintentionally) Manipulate Our Friends – Part 2

In my previous post, I introduced the three ways of stating opinions: as if they are facts, as demands, and as preferences. Today, I will discuss the second method of stating opinions: as demands. What does an opinion stated as a demand sound like?

  • “You must ride roller coasters.”
  • “You will visit Bob’s Car Wash.”
  • “You should complete the project soon.”

All of these sentences describe opinions–no one can provide evidence about the morality of riding roller coasters or visiting Bob’s Car Wash. Also notice that opinions-as-demands usually use words like “must,” “will,” and “should.” These terms imply that there are consequences to following (or not following) the speaker. Most people don’t want to be punished, and might not realize that the speaker is actually describing his or her opinion.

It might be unpleasant to know that the second most-often used way of stating opinions is opinions-as-demands. Naturally, this is not always conductive to compromise and empathy. Perhaps we might benefit from stating our opinions as preferences.

Posted in Psychology | Tagged | Leave a comment

How We (Unintentionally) Manipulate Our Friends – Part 1

Everyone persuades their friends, family, and coworkers at least to some degree. I think we have manipulated others simply by the way we state our opinions. More specifically, we tend to state our opinions as if they were facts, which sometimes convinces others that we are in the right even when we’re not.

There are three ways of stating opinions: as if they are facts, as demands, and as preferences. Each method has advantages and disadvantages that we rarely think about. By understanding the distinction, we can consciously choose how to phrase our opinions (also known as value statements). Otherwise, we subconsciously state our opinions however they come to mind, which may lead to unintentional manipulation of our loved ones–and ourselves.

The first way of stating opinions is as if they were a fact. Out of the three methods, Americans use this one the most. The following sentences highlight a few examples:

  • “Roller coasters are fun.”
  • “Bob’s Car Wash is the best in town.”
  • “This project is easy.”

Compare these to a few statements that actually are facts:

  • “Alice likes roller coasters.”
  • “90% of customers would recommend Bob’s Car Wash to a friend.”
  • “This project is due in two weeks.”

There are several consequences of stating opinions as if they are facts. Most importantly, stating opinions as if they are facts can trick people into believing that your opinion is a provable fact. This can also unintentionally reinforce our own beliefs. If the listener doesn’t realize the distinction, they might think your statement is actually a fact.

In addition, stating opinions as if they are facts does not imply equality between the parties in the conversation, nor does it encourage compromise. It might make the speaker sound more confident, but anyone who notices that the statement is an opinion won’t be convinced.

Next up is the second way of stating opinions, which is sometimes used to imply threats.

Posted in Psychology | Tagged | Leave a comment

Randomness and Bughunting – Antifragility Applied

Today’s entry describes one way in which development teams can benefit from disorder.

In my previous blog post, I introduced the triad of fragility, robustness, and antifragility. The fragile dislikes chaos, the robust is resistant to chaos, and the antifragile can benefit from chaos. I also mentioned that some amount of disorder (stress, change, volatility, variation, chaos, and the like) can potentially improve systems–software or otherwise–and I think that individuals and organizations can sometimes benefit from adding disorder to their environment. What categories do software and software developers fall under, and how can we make our development systems benefit from stress?

iceberg

Like an iceberg, the costs of waiting to solve a problem can be quiet and tough to see. Photo credit: Ilya Haykinson.

I classify software as fragile, but software developers as antifragile. When a programmer is hit by a problem, he or she can recover from it, resolve it, and use that knowledge to prevent related problems in the future. A program encounters an unexpected bit and shuts down completely.

Of course, too much chaos can destroy an individual altogether. I am not advocating for complete disorder. Rather, I am noting that individuals can benefit from a some amount of chaos in the environment. However, it may take a certain perspective to realize how unexpected problems can help an a team of developers.

Development teams can become more antifragile by fixing mistakes immediately (if possible). Consider a fragile team of developers. When they encounter the slightest problem, the entire system breaks. A robust team, on the other hand, is not bothered by the issue. They solve it and move on.

An even better reaction, made by an antifragile team, solves the problem quickly and also finds the root cause. This prevents further errors and allows the codebase to remain intuitive and extensible.

However, a developer (myself included) might think that patching a new bug is not a priority. “It will take too much time,” we think, “and we need to implement feature Y by next week.” So why not put off the fix until later?

First of all, It’s easier to recall the mental model of a certain object on the day it was first designed, rather than six months down the road. In addition, a codebase tends to increase in size with time. By fixing bugs at the source, errors are caught before they propagate. Future extensions won’t have to deal with spotty documentation and untested corner cases if those problems are caught at the source. And finally, we won’t have to inform new team members about software “folklore”–things the company does but few know why.

The previous paragraph describes an ideal situation. In the real world, we can’t solve every problem immediately. Sometimes it may be more valuable to press onward with development than to patch an old bug. Nevertheless, the costs of waiting too long can be quiet and invisible. No one notices a thousand careful captains avoiding an iceberg, but everyone knows about the Titanic.

So let’s avoid disasters. Consider the hidden costs of waiting to fix a problem, and see for yourself how you can benefit from disorder.

Posted in Software | Tagged , , | 1 Comment