Yesterday I wrote about assets and capabilities and while I gave some examples I left off the one capability which has allowed me to consistently level-up over time: figuring out what people want.
Often this is as easy as just asking. Other times it requires some deeper thought to analyze the available info, the options, and extrapolate potential outcomes. This is the skill portion, but that’s not enough – you need to put it into action for it to turn into value. That’s really what this post is about and where the “simple” part comes in.
Make a list of everyone you affect – direct reports, managers, peers, clients, even personal relationships if you like. Next, put down what each of those people want – specifically from you, but feel free to think more generally for extra credit. For example, your direct reports usually want things like a clear definition of success, feedback on what they’re doing, interesting work, money, and any number of other things like training, software, hardware, and dozens more. Your manager wants to know how things are going and that the next milestone will be hit successfully – perhaps another thing or two. Once you have the basics, you can drill into detail for the particular projects you’re working on.
This list is dynamic and needs to be updated frequently. For people you manage, this might be daily as you look at specific tasks. For your manager, weekly should do it. As you get further out to clients, then monthly may be enough.
This should be a simple exercise – given a person you affect, write down what you know about what they want. If you are unsure, then the next step is fill it in.
Once you know what people want, you have your playbook and it’s time to start providing it.
For a direct report, maybe they want to work with a new technology and you find budget to provide training.
For a manager, maybe it’s time to update the project plan or to start looking at the next release – before being asked.
For a client, are they struggling with something which keeps them from using what you typically offer them? If so, that’s a prime opportunity to provide assistance above and beyond your typical offering.
While this entire process really is simple, it’s not easy – especially in the beginning. You’ll feel like you don’t know what people want or you may even doubt your analysis. That’s natural and don’t focus on it too much and instead work to validate your assumptions. Also, the more you practice this the easier it is to identify opportunities to give people what they want as you’re talking to them. You’ll start to make mental updates to your list (which can be turned into actual updates once the discussion is complete) and you can adjust what you provide accordingly.
Lastly, what do you want? How can you make it easy for those who affect you to know that and provide it? It works both ways, but it starts with you.
I love to read and have a rule that whenever someone recommends a book, I buy it ASAP. Lately I’ve also been getting books I see referenced in other books. There’s a ton of research and anecdotal evidence which correlates reading to success and I’m pretty convinced that there’s causality, not just correlation working there. As such, here are some recommendations for things to read to contribute to your success.
Tools of Titans is one of the most interesting and diverse sets of interviews, pull quotes, and anecdotes I’ve ever read. Does anyone else feel like Tim Ferriss is the next Shep Gordon? Read this book if you’re an interesting person, or want to be an interesting person, or want to find other great stuff to read.
Extreme Ownership is referenced in Tools of Titans since Jocko Willink (one of the authors) was interviewed by Tim Ferriss. Read this book if you lead people, want to lead people, or to find out how to become a better team member. Each chapter starts with a (literal) war story from Iraq, but if you’re not into military stuff you can actually skip to the Practice and Application to Business sections which follow.
Rands in Repose is tied with Seth’s Blog for my favorite blog. Michael Lopp is a brilliant manager with enviable writing skills. Read this blog if you manage technical people or you are a technical person. His book Managing Humans is also excellent, but the blog is not to be missed.
Safari Books Online is my secret weapon. Yes, it’s $399 per year and that’s not cheap but combined with their Queue app it’s a bargain if you’re a technical person who likes to learn. In the last year I’ve read through dozens of O’Reilly books and watched a couple of their training videos. The books alone would have cost me triple or more. If you are a developer and like to learn from books, this one is a no brainer. If I were running a company with employees, buying the team version would probably be on my list for recruiting top talent.
Okay, one more just for fun: Living with a SEAL is one of my favorite books to give to people. My friend read the entire thing on a red eye from Seattle to Miami one night after I convinced him to “give it 4 pages and see what you think”.
There are almost no advantages to being the son of a world renowned economist. One thing that keeps it from being a total wash, however, is that I got introduced to the concept of optionality at an early age. I honestly don’t remember when I became aware of it, although I can remember thinking the term “synthetic puts” sounded cool when I was 12 or so. Even though I didn’t understand the underlying math until much later, I grew up with at least a subconscious realization that the ability to choose was worth something.
In my early 20s, I started trading stock options online.
I was horrible at it.
I was buying options, which meant I was paying someone for the ability to make a choice.
I was in my early 20s, which meant that I made really bad choices.
So there I was, paying someone to let me make bad choices. I stopped in my mid 20s after I grew tired of losing money. The concept of optionality stuck with me, however, and I’ve incorporated it into my approach to both software and clients.
On the software side, this often means decoupling. I don’t favor decoupling because it’s cool, I favor it because I’m wrong a lot and want to be able to fix my mistakes as quickly and easily as possible. Decoupling gives you options because it reduces the impact of changes, meaning that you can make more changes. Particularly in business software (and espectially in large enterprise systems), you can bet that change is coming. Requirements change. Systems that need to be integrated change. Business processes change. If your system can keep up with this change, it's a lot more valuable than one that can't.
On the client side, I sell a wide array of options and clients like it even if they don’t realize that that's what it is. Instead of saying, “Here’s the deal: You pay me X and I’ll deliver Y” I almost always offer choices. The actual choices aren't important here, the important thing is that no matter what they choose the work they need will get done. Sometimes that means paying for my own hardware, software, hosting, etc. Other times it means travelling to be on-site with them or their clients. The point is, that by offering them the option(s) to do things their way, I get to charge a premium over someone who simply sells billable hours sitting in front of a screen.
If you can provide optionality that's valuable, you can sell it and collect the premium.
As a bookend to the previous mention of options trading, I returned to it recently for a bit (now in my mid-to-late 30s) and did pretty well. The difference? Instead of buying options, I sold them through credit spreads since I now realize that my value is in providing optionality rather than using it.
If you're unfamiliar with Reflector and its history, you can catch up in under a minute with the bulleted list in my previous post. Since the announcement, I've read every tweet that had "redgate" in it. I read the Red-Gate forum posts. I read the links that are in the tweets and the forum posts. And, I read all of the 132 comments that I received after offering to buy 10 licenses at $35 per (which Red-Gate then matched with 100 more and bumped them up to the $95 Pro version).
As I mentioned in the previous post, there is a lot of information surrounding this event that is valuable to any entrepreneur, executive, marketing person, or product manager. Here are some of the lessons that I've learned from the experience:
Free Is Unlike Any Other Price
I had read that "free" is a unique price in Predictably Irrational by Dan Ariely, but there's a big difference between reading about it in a book and watching people freak out over it. Almost all of the negative posts that I read centered around "Red-Gate said it would stay free and now it's not". I'm guessing that there wouldn't be as much noise if the situation had been "Red-Gate said that it would stay affordable and now it's a little less so" . . . it just doesn't have the same punch, does it? To be clear, I understand that "free" does have some unique properties: zero risk, zero acquisition friction, etc. and I'm not suggesting that people shouldn't feel they way they feel. The lesson learned here is that "free" needs to be treated differently and that it's risky to price anything as free that can't stay that way.
All Information Gaps Will Be Filled
If you've read most of what's been written about this event, you'll notice 2 things about the information:
It's incomplete.
People will fill in the gaps with their own beliefs.
I read everything from "since Lutz got paid" and "Lutz may not have done the deal if it wasn't going to remain free" to "Reflector should go back to being open source" and "Red-Gate installed a timebomb in it". To the best of my knowledge, the details of the deal were never made public. That means that unless you're Red-Gate or Lutz, you don't know the details. As for the open sourceness and timebomb: Plenty of people have pointed out that it was never open source and the timebomb had been there for years before Red-Gate acquired it. The lesson learned here is that any information gap will be filled by someone, at some point and that you might want to consider a defensive move of laying out relevant facts when it's time to announce an unpopular decision.
Non-Physical Products Are Different
People have a different view of non-physical products compared to physical products. If you buy milk from the store, you don't expect it to last forever. You know that it's an exhaustible resource that disappears as you use it. As a physical object, it can't be 2 places at the same time. Non-physical products have non of these limitations. Because of this, limitations built into a non-physical product are often seen as taking something away from the end user. DRM for music, games, and movies is a good example since it so clearly takes away capabilities from the non-physical product. People hate DRM for a variety of reasons, but one of the most common is that it makes the non-physical product behave in unexpected ways. All of a sudden you can't listen, play, or watch – not because your network connection went down but because someone made the media require a continuous connection. That was a limitation that was consciously built into the product. The timebomb in Reflector is similar. Except for trial software, most people don't expect software to expire. When the expiration comes, it's not only unexpected but it's clear that it was put there consciously which can lead to feelings of "you did this to me". The lesson learned here is that if you're going to do something unexpected, make sure people are aware of it and consent to it in order to avoid an emotional response down the road. As a point of clarity, "aware" means that they actually know what's going on which means it can't be buried in a EULA.
Developers Are Even Differenter
I lumped music, games, and movies together above when talking about non-physical products because they all have a similarity that separates them from software: most consumers can't create their equivalent. Once you get into the realm of software, then things get a little stickier . . . all of a sudden you're talking about things that could be created by the end user, although it's often impractical for them to do so. If you narrow things down to "developer utilities" then you're on really thin ice. You are actually targeting a market segment that is often qualified to create the thing you're selling them. Most of the time they'll be very rational about purchasing tools: "This will make me better. It would take longer to create this myself then the price divided by my salary/rate. I should buy this." If something happens to suppress the rationality (like messing with "free"), then they can quickly go into "I don't care what it takes, I'll build it myself!" mode. The lesson I learned is that when targeting developers as a market, it's important to avoid doing anything that might flip the rationality switch.
Conclusion
To cause the reaction we saw over the last two weeks, it's safe to say that Red-Gate made a mistake. What's not clear is exactly where the mistake was made and what should have been done differently. It's not clear because we don't have all of the information. Don't let this opportunity go to waste, though. There are some folks who paid steep tuition for the lessons that you can learn from this experience.
