Archive | techniques 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 🙂

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!

Multi-level Vision

I remember watching a TED talk a while back where the speaker described how to represent data from different scales at the same time. The example had a picture of a house superimposed onto a street map superimposed onto a city map superimposed onto a country map, etc. It was hard to see all of this information at once, but occasionally you’d get flashes of how everything fit together.

Software architects have to do this all the time

One of the most important architectural skills is seeing through all of the layers of a piece of software at the same time. I don’t think you can be an effective architect without this. An architect has to know how a change in one layer will affect all the layers in a system. Often, something that makes sense in one layer is a terrible idea in another.

What makes this even more challenging is that each of these layers may involve different technologies. Not only must an architect have the vision to see potential problems, but they must do so in a way that holds multiple paradigms and structures in place simultaneously while threading multiple paths through all the layers. Occasionally, while doing this, an architect will see everything fall into place and have a momentary, deep insight into the entire system. The challenge then becomes capturing something coherent enough to act on before the insight vanishes.

It requires lots of practice and experience to develop this kind of multi-level vision. I don’t think you can learn how to do this casually—it’s something that you have to work at for a long time. How long? I think the current rule of thumb is for about 10,000 hours.

The Positioning Matrix: A Great Marketing Tool

A friend of ours, James McIntyre, is a B2B technical marketer and one of the stars at McClenahan Bruer Communications in Portland. A while back I asked his advice on what I should do in terms of marketing my product. The first thing he said was to put a positioning matrix together. I looked confused; he elaborated.

What is a Positioning Matrix?

A positioning matrix is a document that helps organize your thoughts on how to describe your product (or service) to a particular type of person in a particular market. Whenever you communicate to your market (via a website, e-mail, presentation, sales call, etc.), your positioning matrix can help ensure that your message is consistent and focused.

Parts of a Positioning Matrix

I don’t think there’s a standard form for this, but what we’re using has the following structure:

  • A column for each type of customer/user in your market
  • A Vision Statement row cutting across all users that summarizes the overall product message
  • For each type of customer/user, a positioning statement describing your product
  • Value Statements that answer “What’s in it for me?” for each type of person
  • Differentiators that answer “How is this different from other products?” for each type of person
  • Sound bites that should strike a chord for each type of person in your market
  • A 50 word statement describing the product/service
  • A 100 word statement describing the product/service

Using a Positioning Matrix

To give you a better idea of what a positioning matrix is and how to use it, I’ve posted my company’s matrix here: Lakeway’s Positioning Matrix.

One place where this has already proven valuable was in the redesign of my company’s website. It helped focus our message, especially as we developed the Flash movie on our homepage. If you’re curious, take a look at the movie, compare to our positioning matrix and feel free to let me know what you think.

Composing a Positioning Matrix

It takes a lot of thought, reflection and feedback to draft a meaningful positioning matrix. The company where James McIntyre works offers this as one of their services. If you’re starting out and have funding, I recommend you check them out.

If you’re bootstrapping (as I am), this may not be an option, so roll up your sleeves, block out some time, brew some tea, and start thinking about why your company exists, what it does for your customers, and how it’s different from everything else out there…and make sure you revise it after you start talking to your market!

5 Principles for Project Success

Last week, I gave a 2-day workshop on project management. I focused on what I call the Five Principles for Project Success. It’s been my experience that when any of these principles are violated, a project is headed for trouble. Conversely, if a project is in trouble, reviewing these principles is critical for recovery.

1. Purpose

Everyone involved in a project at every level should always know the project purpose: who cares about a project and why is it important. People should know the project drivers (e.g., cost, quality, target date, feature set, stability, usability, performance, flexibility, accessibility, …) and how the drivers are ranked. This is the only way to rationally make tradeoffs within and across projects.

The project purpose is frequently overlooked because we tend to focus on the work that needs to be done and often get started on it without asking why. When this happens, we tend to work on tasks we want to work on, not necessarily what’s most important for the client/customer and stakeholders. We don’t move the project in the right direction, if in any direction at all. There’ll be plenty of motion, but not much progress. At some point (when the budget or schedule gets tight), we’ll have an emergency meeting to figure out what should be done and finally the project purpose will be recollected or even spelled out for the first time. Great, but too late. There won’t be room to recover.

The project purpose should be defined up front, and, again, everyone should know it. The purpose should be captured in something like a “Project Charter”. Johanna Rothman describes these charters in her book Manage It!.

2. Planning

The most famous quote on planning is probably from Eisenhower: “Plans are worthless, but planning is everything”. Ike said it in the midst of the Cold War, but it’s a timeless observation. When engaged in planning, we’re considering options. We think through risks and how we might address them. We lay things out, we make assumptions, we make choices. At the end of this we have a plan. However, no matter how thorough our plan or how much thought we’ve put into it, the plan can only reflect what we know at a given point in time. Things change. We may run into a set of unanticipated problems or perhaps the risks we did consider didn’t really have the impact we feared. When this happens, we should adjust the plan. We should re-plan.

Without planning, projects will be left to chance. Risks will come as a surprise and quickly derail a project. People will be constantly shooting from the hip, making decisions based on urgency instead of value, reacting to events instead of anticipating them.

Planning is something we should do throughout a project. When a plan is no longer useful, we should draft a new one. The plan itself is only a snapshot of what we knew at a point in time.

3. Tracking

To make rational decisions about projects, you need to track project data. Period. This isn’t something you get from chatting with someone. When you ask “How are things going?”, you’ll get a response like “Pretty good. I think we’re going to be done with this next phase soon”. What does that mean? What does that tell you? When someone says something like that, I hear “We’re not done yet”. You need a finer level of status than that. You should be able to answer questions like this at any point during a project:

  • Is the project running late? By how much?
  • Is the project over budget? By how much?
  • Which tasks can be started now? Are any of them late off the bat?
  • Is the project resource-bound? Where are the bottlenecks
  • What are people working on?

If you don’t have tracking, you won’t know if your projects are in trouble until the end. Key decisions will be delayed. Teams will miss important dates. The sense of urgency that should have come earlier in the project will come too late.

Tracking project data can be straightforward and easy if you have the right tools. If you set up your projects efficiently, tracking them basically boils down to logging effort left and effort spent. It can be that simple (with the right tools :-)).

4. Demos

Demos are the real measure of progress. If you can show something working, then you’ve actually done something. If you can’t demo anything, then you really don’t have anything of value. Demos are great because they expose assumptions. They ensure that details are looked after. They get everyone on the same page, something especially important when there are several teams involved.

If you don’t do demos, teams that can work separately will — and they’ll work in isolation. Work won’t be integrated until the very end of the project. Everyone will feel their part is on track when, in reality, much of the work is yet to come. When integration finally does arrive, it will take much longer than everyone expects. There will be unanticipated rework, cost, and stress.

Demos are something we should always plan for in our projects. They can be fun. They give people a sneak peek at something that no one else has ever seen. It’s a time for teams to get together and show off, when executives get to drop by and see progress, a time to re-sync before moving forward again.

5. Consistency

Consistency is about predictable execution. It’s about dispatching work efficiently and having clean handoffs across teams. When you have consistency, your organization runs like a well-oiled machine. This can only happen when roles and responsibilities are clear, when processes are well-defined, and when people have the skillsets to play their roles.

If you don’t have consistency, you’ll waste a lot of time reinventing process on the fly. Tasks will be dropped, especially across team boundaries. There will be gaps in process, gaps in task assignments, and gaps in skillsets. Execution will stall and be unpredictable.

To become consistent you need to think through your processes and capture them in some form. Swimlane charts are a good tool to use here because they force you to think not only about what needs to be done, but also who should be responsible for it and what sequence the work should follow. It can be an interesting exercise to get people together to sketch out a process because it will quickly become obvious that everyone had a slightly different view of the roles and responsibilities. Getting clarity around this early-on improves consistency of execution.


These are the principles that I’ve found to be crucial for project success. Time and time again, these are what I point to when projects go wrong. Of course, there are other principles “embedded” in these five (e.g., communication runs through everything above). If you can think of a principle not covered above, please feel free to comment!

Debugging with the Scientific Method

One of the best techniques I’ve run across for debugging software is the Scientific Method.

The Scientific Method for Debugging

It’s actually pretty simple, but I’m always amazed at how quickly it can bring you to the root of a problem. Basically, it goes like this:

  1. Enumerate the evidence you’ve seen regarding the issue.
  2. Before changing any code, take a guess at what might be happening. It doesn’t have to be a good guess—it just has to be something you can test. This is called your hypothesis.
  3. Come up with a way to test your hypothesis. You want something that can give you a “yes” or “no”.
  4. If your hypothesis is correct, you’ve found the issue. Fix it and move on. If your hypothesis is incorrect, log this fact as the next piece of evidence and then come up with a new hypothesis based on all of the evidence, including this.

For a typical issue, it takes me 2 to 3 hypotheses to get to the root cause. For tougher issues (especially those that involve recursion or graphs), it takes me 5 to 7. In either case, it’s a great way to prune off areas to search. It is by far the most effective way of debugging that I’ve ever found. I’ve often noticed that issues typically requiring a day (or more) of debugging can be dispatched in an hour or so using this technique.

Modification using TDD

One powerful modification is using test-driven development with the Scientific Method. This is particularly useful when it takes many steps to duplicate the issue using the application. It’s even more useful when duplicating the issue requires you to delete and re-add data.

Here, the first step is to duplicate the issue in an automated test. This is the hard part, but the part that will save you the most time. Once you have this going, the tests of your hypotheses will be the same as your TDD tests. You add tests to check your hypotheses until you’ve proven your hypothesis correct. A bonus is that once you’re done, you’ll have some regression tests in place that actually exercise something that broke.

Believe it or not, it’s kind of fun to debug this way. You feel like a scientist wearing a white lab coat and jotting notes into a log book (I assume you think that’s fun 🙂 ). You set up experiments to see if you can trap bugs. They can be surprisingly evasive, but the scientific method always catches them in the end. Bwahahaha!