Archive | advice RSS for this section

Listened to Eric Ries’ e-Corner Talk – Guess It’s Time to Pivot

A few months ago, Eric Ries gave a talk as part of Stanford’s e-corner series (“e” stands for entrepreneur). I remember listening to the first part of his talk, but for some reason I never finished it. I finally ran across it again, so I decided to listen to the whole thing. I’m glad I did.

He described a whole range of lessons learned from the various startups he’s been part of (in fact his blog is called Lessons Learned). One lesson that I found particularly relevant to me was that all successful startups “pivot”. When a startup introduces a product to a set of potential customers, they usually learn that some of their assumptions about the market were wrong. Customers will let the founders know this by saying things along the lines of “Well this is an interesting product, but what would be really useful would be X”. This feature may only be tangentially relevant to your current product. However, if several people ask for X, there might be something there. A pivot is re-orienting your product so it can do X or building a new product that does X in a viable way. You keep one foot in your current product and “pivot” to place your other foot in the new product. If you make a series of pivots based on customer feedback, you will home in on what your customers will buy.

While this sounds easy, it’s actually very hard, in practice, for an entrepreneur to do. After all, you’ve spent a lot of time thinking about a problem and building a solution to it. When you hear someone say your product is “interesting” and ask for X, your first reaction is to dismiss this idea out of hand. You may be right; you may be wrong. It’s hard to tell. Maybe your product is too far ahead of the market (e.g., WebTV, Newton). Maybe you’ve created a disruptive technology that has to find its niche first (e.g., 2.5″ hard drives in laptops). In any case, when several people ask for X after you’ve shown them your product, perhaps it’s time to listen.

Time for Lakeway to Pivot

For the past few years, we’ve been driving very hard at developing Frontier. It’s a beautiful application that addresses key management problems that, before Frontier, have defied solution. However, for the past two years, whenever I show Frontier to engineering executives, they always seem to ask for X. After listening to Eric’s talk, I’ve thinking more seriously about how X and Frontier could live together. I think I’ve come up with something that could work. I guess it’s time to pivot and see what happens…

P.S. No, I’m not going to tell you what X is 🙂


Met with a VC for coaching last week

The SDForum (which stands for “Software Development Forum — not San Diego Forum 🙂 ) has a nice program where you can meet with a VC for 30 minutes, not to pitch, but to get some advice 1-1. I went to a session last week on Sand Hill Road and thought I might share the advice I got.

Rino: How do I find customers in enough pain to try Frontier?

VC: Target potential customers more. Find customers that are similar to your current customers. Ask your current customers how they market themselves and look there. Have e-mail and phone versions of your hook and elevator pitch. Be aggressive with e-mail.

Rino: What do you mean by aggressive?

VC: Keep e-mailing people every couple of weeks. Don’t stop until they ask you to.

Rino: We’ve got a lot of depth on the software, technical and UI side, but we don’t have anyone with Marketing or Sales experience. Should we be trying to find someone to join our team?

VC: Not at this stage. Your first goal is to find a set of core customers. This is something you can do without a sales person. You need to go out and target your customers very precisely. Figure out who would benefit the most from your product. Understand the value proposition that you’re pitching.

Rino: Our product represents a paradigm shift in the way people manage projects and engineering teams. Do you have any advice on how we might find people who are willing to try something different with a tremendous upside — the people that Steve Blank calls “Earlyvangelists”?

VC: You need to outline exactly what a customer needs to change in order to use your tool. Write this down explicitly. The bigger the change, the harder the sell. If you can find a way to have the tool adapt to the way they do business right now, that’s probably your best angle.

Nice presentation on creativity by @jted

Did you catch the nice presentation on creativity by Jason Theodor on slideshare today? If not, here it is:

It’s nice to see someone put so much thought and reflection into something. It’s like a doctoral dissertation on creativity. Lots of great insight here — probably a decade’s worth — presented effectively and delightfully. Super job, Jason!

Why Engineers are Lousy Salespeople

It’s been about 6 months since I moved back to the Bay Area. Since then, I’ve been attending various entrepreneurial meetings and trying to network with people. I’ve noticed that there are two types of people at these meetings. The first type have an idea for a product and “only need” a team to build it. The second type of people are those who’ve built a product and “only need” to sell it (I’m in the second group).

The first group tends to be non-technologists while the second group tends to be people with engineering backgrounds (or at least technical personalities). This leads me to believe that engineers are lousy salespeople. Here are some reasons why:

Emotion sells

According to Jeffrey Gitomer (he’s the guy that writes that little red salesbook), sales are first made emotionally and then justified logically. A good salesperson appeals to your emotions to get you excited about buying a product.

When you think of someone with a technical background, a person like Spock comes to mind. Engineers strike people as either passionless or (after you push them far enough) very angry (just like Spock).

If emotion sells, engineers are clearly at a disadvantage. The only time engineers make sales is if the customer already realizes they need a solution–when the customer is past emotion and justification and is willing to pay for something that works.

Getting Past No

Engineers take things at face value. If an engineer says, “Would you like to try this product?” and the client says “no”. The engineer will say “ok” and then stop talking. Engineers don’t get past no. We assume our clients are rational and that after we’ve presented our case, they make their final, irrevocable decision.

I have an 8 year old son who (I’m pretty sure) won’t be an engineer. He’s never taken “no” for an answer. In the morning he might say “Can I play Doodle Jump?”, and I’ll say “no”. A few minutes later he’ll say, “I haven’t played Doodle Jump for a while. Can I play Doodle Jump?”, and I’ll say “no.” At breakfast he’ll say, “Did you know that one of my favorite games is Doodle Jump?”. This level of discourse goes on throughout the day until I am finally worn down and wearily say “yes”. (Maybe in a few years, he can sell for me 🙂 )


Engineers Don’t Socialize

I think it’s fair to say that most engineers are introverts. We aren’t energized when we talk to new people. It’s quite the reverse. At the end of every networking event, I am very tired. It’s hard to maintain and keep track of so many conversations. It’s hard to remember who you’ve talked to and what they do.

Unfortunately for us, making connections is how you make sales. By networking, you can build a reputation. You become more visible. You become more trustworthy.

This tends to get easier over time, but I think that’s because you start recognizing people. The conversations start being more about “how are things going?” rather than “so, what do you do?”

Pursuit of Perfection

Engineers don’t like to be wrong. We don’t like to make mistakes. We’re trained to get the right answers (and that there are right answers!). When building medical devices and bridges, this is a great attitude. When dealing with people and potential customers, it’s not.

We need to be willing to accept failure. We need to expect failure. We have to keep trying different things until we find what works. There is no formula or algorithm that can avoid this. As a group, engineers have a hard time tolerating failure. When selling, failure is a big part of life.

The R in R&D

One thing that we should leverage more as engineers trying to sell something is the “research” aspect of our background. Research is all about trying something, understanding why it didn’t work, and then using that information to try something new. This is something engineers can relate to, and I think it’s the best way for us as engineers to figure out how to sell our products. It’s not straightforward or rational, but if we work at it, we should find something that works (I hope!)

We’ve been trying to figure this out. It’s been a slow process. I believe we’ve been doing the right things, so we need to keep finding new things to try. I think we have to give up reading about how to do this and actually talk to someone who’s done this. We need to find someone who can show us the ropes of growing a business and marketing and selling. We don’t need help writing software; we’re great at that :-).

I’ll let you know how it goes. If you have any thoughts or recommendations, feel free to leave a comment. Thanks!

“Success is the ability to go from failure to failure without losing your enthusiasm”

Evidently Churchill said this. I’m not sure where or when. It’d be nice to think he said this during the darkest hours of WWII, but for all I know it might’ve been at some conference in the 50s (kind of like Eisenhower’s “Plans are worthless, but planning is everything”).

It’s an interesting quote. I think most people take this to mean “don’t give up” or “hang in there”. That was how I initially viewed this. However, I think there’s a better, more constructive way of looking at this, especially from the perspective of a startup.

Failure is active

“Going from failure to failure” is not just about enduring hardship passively. Failure is something active. It comes after actually trying to do something. It only happens after real effort. You can’t go from failure to failure by sitting around and waiting for something to happen. “Achieving failure” is real work.

Failure is also a public thing. Others can see it. In fact, others must see it because if no one sees it, you didn’t really fail—failure is a kind of social interaction. Sending e-mails to potential customers without getting responses doesn’t count as failure–maybe they were on vacation, maybe their e-mail filter stopped your message, maybe your message got lost in the hundreds of new messages they got that day. However, when you talk to someone in person and they tell you they don’t need your product, that’s the kind of failure you need to reach, the kind of failure that gives you the opportunity to go to the next failure enthusiastically. This type of failure teaches you something: your message was off, or your ROI assumptions were too strong, or the problems you’re solving aren’t important, etc. Whatever it is, you can use this to improve for next time.

When can you ever fail?

“True failure” happens when you’re too scared to try. It comes when we don’t want to look stupid or wrong. “True failure” stems from a fear of failing.

When do you ever really “succeed”?

When you go from failure and strive for the next failure, sometimes you fail to fail. I think that counts as success 🙂

Pulling Threads

Son #2 was wearing a shirt that was embroidered with “Istanbul!” (my parents bought the shirt for him on one of their vacations). The thread making up the “I” in Istanbul came undone and he was pulling on it, causing the “I” to disappear. We told him to stop because he would start erasing the whole word.

It’s the same in software

One of the software teams I used to manage talked about the danger of “pulling threads”. In any piece of software that’s been around long enough, there are bound to be parts that are just a little bit off. There might be an extra parameter that you shouldn’t need, or there might be some extraneous code somewhere. You might think to yourself, “Well, why don’t I just fix this right now since I’m looking at it?” That’s a good attitude, but sometimes pulling on these “loose threads” will cause the entire module to unravel. Often, you may find that the thread runs through several modules and fixing this will involve touching a bunch of files.

The danger in pulling on threads in your spare time is that you won’t have enough spare time to finish. Inevitably, you’ll have a half-done pile of work that isn’t fit to check in and that doesn’t provide any visible value.

If you want to pull on threads, tie them to features

The best way to pull on threads is to associate them with features. If you can let features drive things, you’ll pull on the threads that matter. You’ll end up with cleaner code that does something new. It’s really hard to justify work that only (potentially) reduces maintenance.

Pre-emptive thread pulling

Sometimes you can prevent future thread pulling with a little thought today. One of the features that people have asked for in my company’s product is the ability to log notes against effort entries. On the surface, this is easy to implement. You just add a notes field to an applied effort entry and there you go. However, I’ve been hesitant to do this because I know this would create a thread that would have to be pulled at some point.

How do I know this? It’s because I know the data architecture of Frontier, and I know this isn’t the right way to solve this problem here. The right way involves architectural changes. It’s a little more involved, but the result will be something much cleaner and much more powerful. So that’s what I’ve spent the past week doing–pulling this thread before it exists.

Don’t do too much pre-emptive thread pulling

Too much pre-emptive thread pulling, though, leads to overdesigned software. You’ll never get it done. You’ll spend too much time analyzing cases and sub-cases, and inevitably, one of the cases you hadn’t considered will be the one that turns out to be important…and many of the cases you did consider will turn out to be threads that will need to be pulled some day 🙂

Thinking about replacing your light fixtures?

First of all, just do it! Changing your lights can make a huge difference in your living space for little cost. As home improvements go, I’d rank it right after fresh paint in terms of bang for your buck. For some reason, though, it’s hard to get motivated enough to do. You have to go the hardware store, you have to pick the lights, you have to find your screwdrivers, you need to figure out which fuse goes to each light, you have to steel yourself for the inevitable surprises when the old lights come down. Ok, there are lots of reasons it’s hard to get motivated, but do it —just do it; it’s worth it.

This weekend, I replaced our outdoor lights and two sets of track lights. Each round, of course, had its own challenges. One’s mounting box had to be rotated 90 degrees for the new light. Fine. Just take the nails out, rotate it, and then put the nails back in. One mounting box was broken and wouldn’t hold a screw (so that’s why the light was always leaning!). Fine. Go to Home Depot, buy a new one and replace it. One didn’t specify which drill size to use for the sheetrock anchor. Fine. Drill a hole in the box it came with, and see what works. I’ve got several more lights waiting, several more “fines” to come.

But that’s ok. At the end of the day (literally), things look brighter (literally) 🙂