Drawing Lines, Not Dots

A dot on a graph with no context is often fairly useless unless you have already established a sense of context. A good example from my last job: if I tell someone that they used 200 kWhs last month, for the large percentage of the population, that doesn’t mean anything unless they also know how much others are using, or how much they used in the past. Another situation where this has come up for me is when living in countries that use Celsius for temperature. Is 30 degrees hot? cold? shorts? pants? shirt? no shirt? — after living there for a while, you get a sense for it (30 is pretty warm by the way), but without having spent one’s life getting familiar with it in the same way as Fahrenheit, it’s a complicated proposition.

To give credit where it is due, the concept for this post was inspired by a post from Mark Suster on entrepreneur/VC relationships (which is also worth a read).

dot with linesIt can be helpful to remember this when presenting yourself to others or evaluating your own performance. Without comparisons to others or your past performance, a single piece of information leaves a lot to be desired. As Mark points out, when evaluating a company for investment, meeting an entrepreneur a single time tells you very little about the company. Are they high revenue, but trending down or flat? or are they low revenue, but doubling every month for the past 6 months? With a single point, you can make up whatever trajectory you want from your data.

This same concept can be applied to job hunting, dating, and any other interpersonal situation where you are looking at a long-term outcome involving people. Mark covers this thinking pretty well in his post, so I won’t re-iterate here.

This same type of thinking can also be applied usefully to self-evaluation to provide better perspective, and for driven, hard charging people, it can help provide some checks to negative self-evaluation or frustrations with progress. For example: say I’m an athlete looking to perform my first body-weight pull up, and I’ve been trying to reach this goal for 6 months. I’m still not there. Looking at my current state (can’t do a pullup unassisted) and comparing it to where I want to be (can do a pullup unassisted), I could very well look at that as a failure. That’s a point on a graph. Now, let’s back up six months to where I didn’t have the strength to deadhang on the bar for more than 5 seconds. Now I can not only hang on the bar for more than 40 seconds, I can can perform assisted pullups using a stretch band. Suddenly my hopeless situation becomes a trend line which is strongly going in the right direction. That’s a much different story.

Again, the same concept can apply to skill building, working out, relationships, etc.


I’ve noticed a few situations where this model can break down if not observed.

Moving Cohort

cohort movementComparing one’s self to a group can be a great way to get a sense of where you fall in within the group’s skill set, but can be terrible when measuring improvement in your own skills. For example, I’ve always worked in startups with smart, ambitious young people and thus find myself comparing my skills and abilities to the highly skilled and intelligent people I work with. As a result, I often feel that I’m not progressing. What is in fact occuring is that our entire cohort is progressing and improving together. So when I look to my local cohort, I find that it often looks the same month over month. What I’m failing to realize in this case is that the cohort itself is moving in relation to the outside world.

Looking to Extremes

local trendsWith limited, discrete data points, evaluation can be flawed by sampling error. An example of this in life would be: evaluating sport proficiency after having lost of game or relationship success after having broken up recently. These are both likely going to be relative minimums, and not representative of the overall trends. Make sure your sampling isn’t being biased by current state of mind and that your time horizon isn’t  distorting your trend line.

Looking Out

I’m sure I haven’t covered all the possible ways this could go wrong, I’d love to hear if any of you have other thoughts on avoiding false interpretations and ways to better use lines and not dots in keeping yourself happy, healthy, and wise.

Prioritizing Tech Debt and Opportunity Cost

Last week I found myself arguing with one of our engineers at Simple Energy about the ‘correct’ implementation of a feature. This argument centered around the issue of accruing ‘tech debt.’

(If you’re not familiar with the concept, check out the wikipedia page.) He argued that a longer implementation time to add additional functionality would save us time in the future. I argued for a shorter, less full functioning solution which was ‘good enough,’ but would likely lead to a small number of distractions for the engineering team in the future. We have very intelligent and highly capable engineers at Simple Energy, so I knew when we couldn’t reach a mutually agreeable conclusion, that I was missing something.


One of the most difficult things to work into any engineering workflow — in all the startups I’ve worked at — has been tech debt. This issue becomes highly charged at times because it is painful to deal with for the engineering team, but often hidden or difficult to see for the business decision makers. Having previously coded and led engineering teams, and now leading a product management team, has given me perspective into both sides of this argument, yet I still found myself frustrated trying to explain my position.


Then suddenly it hit me. The engineer was convinced that his side had merit because in spending extra time building this feature right, he would be saving more time than he spent in the future. There was a clear net gain, so why would we not build it? The answer is actually relatively simple: opportunity cost.


Opportunity cost is an economic concept used to address the allocation of a scarce resource towards mutually exclusive investments. In the tech debt scenario, our scarce resource is developer time and the mutually exclusive investments are specific instances of tech debt.



Let’s look at an example to bring some clarity to this. Let’s assume that I have 1 engineer across a four week period and 4 pieces of tech debt with estimated paybacks over the next 18 months. (Granted it’s never this black-and-white in the real world — maybe just try to put it in hours, days, weeks, months instead.)

Item Initial Cost Time Saved — over next 18 months
Issue A 3 weeks 5 weeks
Issue B 1 week 4 weeks
Issue C 3 weeks 8 weeks
Issue D 6 weeks 5 weeks


Looking quickly at this list, we can see that Issue D should simply never be address. It has a net value of -1 week of productive time. From there it gets trickier though. We have 3 issues, all of which will provide net productivity gains from completion.


Yet we don’t have infinite resources; we have 4 person-weeks of time. Assuming the repayment of the debt is simply evenly distributed across the next 18 months, we will want to make sure that those limited resources are being used to address the largest gains possible first. In this case, Issue B wins by providing us with a 4x multiplier on our investment. Following this, Issue C gets us a 2.67x multiple and Issue A returns 1.67x. Therefore, our best option is to invest our 4 weeks into issue B followed by Issue C, returning a total of 12 weeks of benefit for our 4 week investment.


Looking at this through the lens of opportunity cost, we see that addressing feature A comes at the cost of not addressing 2 higher return issues, leaving us with a less-than-optimal outcome. This means our best choice is not to address issue A0 at all in this scenario.


This is the piece I was missing while explaining why I didn’t believe we should have been addressing the issue raised by our engineer. While building this feature ‘right’ would cost us roughly a week and likely save us 1-2 weeks of wasted time in the future, there are a number of other items in our tech debt backlog which we could be spending time on which will provide higher-than-1-2x multipliers on time investmented. Those are where we should be focusing our time, or we will lose ground with competitors, or worse, run out of capital before we reach our goal.


Coming Soon:
All this theory is nice, you may say, but how the hell do I intelligently put tech debt into my feature backlog? Well, that’s for another blog post.

Should I Use a P&L as a Product Manager?

I was recently trying to determine the value of building a P&L for some development projects. Concerned that it might end up being a time sink that doesn’t pay off in the end, I asked a mentor of mine for his thoughts. Here’s his reply:
I think if you approach the per project P&L with a big grain of salt, it can be a very useful tool. The grain of salt = your P&L will never be precise and you get diminishing returns past a certain point. Your instinct about using rough numbers and not spending much time is right on, and in fact I’m guessing you wont be able to find much of the accounting info you’d want so you’ll be left making some reasonable assumptions (read: guesses) into your model.  Before you’re done, you’ll have a bunch of numbers that are not at all “accurate” but are very useful for getting a ballpark sense of the world. That ballpark can help you and the team make decisions as well as look for things that are extreme corner cases that you might be overlooking.  As you note, this model could also be useful for evaluating your backlog and again you’ll just be using educated guesses about features::business performance. You don’t have to know exact numbers to answer “does this feature help us sell more? is it a little or a lot? does it help us renew the customer? etc” and the model will help you have a framework for thinking through those questions.


I think there might be some sensitivity to calling it a P&L. Instead maybe “business case” or “pro forma project financials” something like that. I’ve also seen people get very sensitive about actually quantifying expense of employees, especially if its a team that isn’t used to a lot of accountability. Just some things to consider.
On a side note, this could also help you spotlight the “one off” stuff you might be doing per customer deploy. That kind of stuff while sometimes necessary is a very dangerous, slippery slope and you’ll feel the pain first as the person responsible for the product. By definition, one off features are not scalable and don’t improve the overall product.


Ideally you as the product manager would say “no” whenever you see one. That’s usually not how things work, but having this model and a sense of the cost of doing a one off – in time, $, even feature trade offs – can help you start making the case to say no.


– Eric Wu (@ewu on Twitter)


This struck me a spot on, so I figured I’d share it. Hope it’s useful.

Black Boxes and Filling in the Blanks — Early Dating and Compatibility

Dating has long been a subject I’ve avoided on my blog. First, because I tend to want to write things about dating when I’m feeling frustrated with it and I don’t want all that logged in the public record. Second, it’s usually a lot of personal things. I try to write when I feel that I have something useful to contribute to a discussion. I’m allowing myself this post as an exception because I feel like it satisfies the requirement on contributing to discourse and thus I would appreciate your comments and thoughts.

Anyone who’s spent some time with me likely knows that I go on a decent number of dates. Typically a lot of first and second dates and every so often I actually date someone for a bit to see if things work out. I’m single at the moment, so things have not worked out, but I manage to wake up most mornings feeling optimistic that they will some day.


I recently went on a few dates with an attractive young lady with whom I felt some chemistry. Fast forward a bit and I find myself on a hike with her where she’s telling me that she just doesn’t feel that we click and she doesn’t want to date me any more.  I wonder:  What happened?  I need some better information here.

The beginning of the end was this (as she told it): I had been fighting off a cold for a few days before our last date. At the beginning of the date, I gave her a quick kiss and we went on with our date as planned. About 20 minutes into the date, I mention that I had been fighting off a cold. She was subsequently pretty unhappy about my kissing her while sick.

The Model

I won’t go into the rest of the details about why we won’t be dating any more, but this particular story made me realize something:  There are two  kinds of changes people can make in relationships — one based on denying one’s self and one based on new knowledge. (There are probably others too, but for the sake of this idea, let’s discuss these two that are on my mind now.) Denying one’s feelings is the type of change that people talk about when they say things like: “don’t try to change your partner.”  I agree with this sentiment. It’s not possible to change someone, one has to do it for one’s self.  The interesting type is change based on knowledge, which I believe can be very healthy.

Back to my example of kissing this woman. Before she got upset, I had not thought twice of kissing her — I was borderline sick, I didn’t make out with her, and in the past I’ve had a lot of women I’ve dated tell me that they didn’t care if I was sick and would kiss me anyways. (Now I don’t want to say that she was in any way wrong by being upset by this, that is entirely up to her and I feel bad for having upset her by kissing her.)  The question I have to ask is this:  Did this represent a fundamental deal-breaking difference in how we live our lives, or is it bad information?

Speaking for myself, I believe it was bad assumptions and information.  Suppose I have a black-box machine that accepts apples all day and turns out apple pies.  If you watched it take a handful of apples in and  saw an apple pie produced, it would be reasonable to assume that it can make apple pie.  Assuming that the machine would need fundamental changes to behave otherwise is a mistake, however.   Without understanding the fundamental building blocks of the machine, one can’t make that assumption.  Perhaps if you put in bananas and rum, you’d get bananas foster.

The analog for this as part of my previous story is this:  my fundamental building blocks dictate that I’m fundamentally a compassionate person (I think so, at least).  Given those blocks and different input knowledge (“I really don’t like getting sick and don’t want you to kiss me when you are”), the output would be different.   I would avoid kissing a woman who expressed a desire not to be.   Not because I had to deny my true nature to do so, but because my knowledge of the situation changed.   Given new information, my actions changed.

Going Forward

How is this useful?  It helps to ask oneself when considering compatibility if an upsetting event one is revealing the building blocks of the person’s being or if it’s merely unlikely or unreliable input data.  One of the hardest things about early dates is navigating through communication mismatches. We all have our backgrounds and assumptions about the world that we bring with us into any new relationship:  she may say something she meant as endearing that he hears as an attack, or he might invite her to a restaurant where unbeknownst to him she got food poisoning at once.  These can either be lack of information, which is easily remedied, or they could be signs of fundamental incompatibility — these types being oceans away from one another in meaning and importance.

Avoid the latter by sharing what comes up and giving the person information they may be missing:  what you perceive, what you feel about it, and what you want/don’t want.  It may change the output, it may not, but don’t see an apple pie come out and assume that’s all they’re capable of if what you really wanted was some ice cream.  You are always communicating — it is literally impossible not to send out information about yourself every moment.  Try to fill in as many blanks for the other about who you are and what you feel and want, or they will fill it in with their own historical data — which, if they are anxious, will be anxious thoughts and beliefs and feelings (not ideal!).

Premature Optimization and the 95/40 Rule

95/40 RuleI drew this diagram on my whiteboard several months ago to explain to a friend why eating a Standard American Diet (SAD) and trying to fix it with supplements is foolish. The SAD is the column on the right, achieving, for argument’s sake, 40% of an optimal 100%. The column on the left is something closer to an ideal diet for this individual (the Paleo Diet in my case). The effects of supplementation are the small 1% bars on top of each column. Sure, they both get you 1% closer to ideal, but who gives a damn about going from 40% to 41%? The difference is negligible.

After drawing this chart, something interesting occurred: my roommate and I started to draw connections in dating, work, and life in general. For example, suppose I go on a date with a girl who doesn’t like science fiction. That’s a 1% issue in my case. Maybe I can convert her to love Firefly and Asimov (or get over it), but focusing on this 1% improvement prior to looking at the starting point is flawed. If she loves reality TV and despises exercise, these fundamental issues create a poor foundation on which to worry about moderate improvements.

There’s a saying from computer scientist Donald Knuth, “premature optimization is the root of all evil.” If you hate your boss, your commute, and your daily tasks, who cares if the coffee machine is being replaced with a better one? Focusing on minutiae when fundamentals are missing is folly.

The same conclusions can be attributed to learning new skills just as easily as one’s job or diet. With tango, if my fundamental approach to the embrace and leading is broken, who cares if I know how to do ganchos? If one’s diet is 70% grains and sugar, taking a multivitamin isn’t going to fix it.

All this is related to priority of learning and energy expenditure. Find a reasonable foundation, then find the biggest wins with the least required investment and complete them. Then find the next, and repeat. Don’t build a job or a relationship on a flawed foundation, it’s not going to get dramatically better by making incremental improvements. Keep looking until you find a solid foundation, then improve.