Adopting Other Peoples’ Designs

I discovered a dangerous phenomenon the other day over conversation with my co-workers Bret Victor and Glen Chiacchieri.

Bret was speaking of the requests he gets to release the source code for his prototypes, and his rationale behind not doing so — that it could lead to innovation halting, because the release creates a standard for what products should be.

I realized,

When an inventor creates a tool and makes it available to the world, the public has a tendency to simply accept the tool as is, use it, and stop thinking of new ways to do things. (thus halting development of the product).

Example #1: the Pie Chart

Pie charts are pervasive…



… And a poor way to represent information. (See Edward TufteThe Worst Chart in the World, and Oracle’s Reasons Not to Use a Pie Chart)

A simple example illustrates that pie charts make it difficult to make comparisons between two quantities. See:


What if we represented the same information like this, instead? This illustration enables us to make direct comparisons between quantities.


Because pie charts cannot spatially fit all information, they also are pleasantly accompanied by a key (right-hand side), which attempts to illustrate what all the components of the pie chart designate.


Could we design another way to represent this information — one that doesn’t require you darting your eyes back and forth to understand the information?

What about this?


Okay. Maybe not as aesthetically pleasing. Perhaps a reason why people use pie charts is because all the circles look pretty. But I would argue that we should not sell ourselves short — can we not have a representation that is both intuitively functional, and aesthetically pleasing?

I re-designed a representation of the same information; illustrated below.



So what?

These are just pie charts. Okay, it’ll take a millisecond longer to process the percentages. Why does it matter?

I think we vastly underestimate how good the quality of an experience (in this case, understanding and exploring the world) could be, because we already have models in our heads of what the medium is currently like.

One step further: Understanding Bayesian Probability

Another way to view this idea is through the lens of Bayes’ theorem. The traditional example is the cancer testing scenario, where you’re presented with a series of probabilities.


You are typically asked:

Assuming you have a positive test, what is the chance you have cancer?

When calculated out, the number seems much lower than expected.

Some of us simply accept that our brains do not intuitively grasp probabilities, but I’d argue that statistics is only unintuitive because we don’t have proper representations.

How would you design another representation of Bayes’ Theorem?

More to come.

Hamilton and His Facility with Words

When I was in grade school, one of my favorite English teachers would often remind us, “if you can write, you can do anything.” I would always think, “well of course she’s saying that… she’s an English teacher.”

I’m reading Alexander Hamilton’s biography, and he had quite a facility with words, even when he was a teenager growing up in poverty-stricken St. Croix. When a storm devastated the island inhabitants, Hamilton wrote, “…the ear-piercing shrieks of the distressed, were sufficient to strike astonishment into Angels,” in a letter to his father at the tender age of seventeen.

Hamilton may well have stayed in St. Croix for the rest of his life had the Gazette not picked up his letter and published it in their newspaper anonymously. The island governor demanded to know who wrote the letter, and a group of local businessmen raised a fund to send Hamilton to America to be educated.

Before we had writing, we always needed to be in the same place at the same time in order to communicate. The appeal of writing is that it allows you to exchange ideas without time or place needing to be relevant. When I look at some of my role models — I often realize that they’re not particularly smarter than many of the other people in my life — rather, they document their thoughts. Without Paul Graham’s essays, his ideas about the world would be trapped in his head and few would be privy to them. Writing is much more scalable than conversations.

Staying flexible, always

During my last improv class, we did an exercise where everyone had a monologue. I was surprised at how each person was able to make a scene come to life with a beginning, climax, and end so seamlessly. When one of my classmates Olga went on stage and was given the location ‘ice cream shop’, she immediately transformed into an ice cream shop server. As she pranced around the shop, she sampled a taste of ice cream and made the ice cream cone come to life. She took a few licks, and then scolded the ice cream cone for making her butt big, but wrestled with how delicious he was. She finally decided to toss the ice cream in the trash. Every person appeared as if they had been preparing for this scene for the past week.

But none of them had any even preconceived notions in mind. They had all been given a random location on the spot, and had to create a scene based on that location.

I notice an analog in programming. When I was pair programming with our front-end developer Bruno today, I asked why he had defined a function in class A but not in class B, I expected him to be prepared with an answer. Instead, he said “Let’s investigate” and opened class A, going line by line to trace back where the method was being used. He realized that there actually was no need for that method and we ended up taking it out.

You can’t know the answers to some things in life. And trying to hold everything in your head is exhausting. What you can do is be quick to adjust in the moment and execute on the spot.

The Wikipedia Effect

A popular strategy for bootstrapping products is what I like to call the Wikipedia Effect. Wikipedia didn’t set out to build an entire encyclopedia by themselves — they knew their comparative advantage was not in knowing all of the information in the world. Rather, individuals all over the world would likely have more knowledge about topics spanning zoo archaeology to Dostoevsky than a single company ever would. The Wikipedia Effect is identifying what people are good at, and leveraging their strengths to create value.

This strategy is difficult to internalize, because in order to execute the strategy effectively, we have to recognize our weaknesses, and humans typically have defensive, emotional reactions — ego barriers — that stand in the way of progress. Those who get over the ego barrier, might be prone to an engineer’s mindset — wanting to understand and implement every piece of the puzzle, instead of outsourcing their weaknesses to another party.

My friend P is currently working on his next venture. P doesn’t have a software background, and instead of spending a year learning programming, he quickly recognized what he was good at, what he was not good at, and hired a product manager and two engineers as contractors. He built the product in 6 months and already has several customers.

The Wikipedia Effect isn’t the only way to build a company. Some people go to coding bootcamps, learn how to build the thing themselves, build the thing, and then earn customers and revenue. This path, however, is harder and requires more time and effort.

Validate before building

A difficult concept to internalize for those first starting a startup is validation. Founders might talk to people about the idea, try and evaluate the feasibility of the idea, and get caught up in implementation details, making market need an after thought.

With my first company that focused on automating drug development for pharmaceutical companies, K and I spent many of our days reading research papers about Alzheimer’s and the nuances of beta amyloid plaques. We were learning a lot – but not exactly about our product-market fit.

After the first company, we decided to prototype a genetics product. We instead started with market need and put up a landing page for the product, set up a ‘Pre-order now’ button, ran an ad campaign, and asked people for feedback. While we had one customer pre-order our $500 product in the first few weeks, we also learned about the idiosyncrasies and doubts of our target consumers much more quickly than the first time around.

That said, whether a product can be adequately user-tested or not depends. Enterprise products that are only used by one person are easy to user test. Consumer products, on the other hand, tend to be more difficult, especially if they have a social component and require network effects for the user to realize value.

The “Appearance of Success” Trap

The first company I worked for out of college had a lot of politics*.

“Maybe politics is inevitable. And part of having a job is learning how to navigate people and make your contributions visible so that you can get promoted.”

I thought. So of course, I spent considerable effort on making my contributions visible. While I accepted the fact, I was frustrated and believed there ought to be a better way. I realized I felt as if I needed to appear successful because there wasn’t a clear definition of success. Our teams had no OKRs or systems for decision-making. Because there wasn’t a clear definition of how an employee is promoted, I thought I could get there by schmoozing with the C-suite instead of finishing the mock-ups for our next product.

When success is poorly defined, people find ways to achieve the appearance of success.

When I asked K at Uber whether people were ever promoted because they were good at appearing successful, but didn’t have the skill. She replied, “No, if they didn’t have the skill, they would be fired.” She explained that at Uber, each team and individual knew their definition of success, and if they didn’t meet that criteria, they would not advance.

When success is clearly defined, people are no longer making decisions based on how others will react, but rather, on what they genuinely think will help reach the team’s set goals, moving the company forward.

* Politics is defined as when people choose their words and actions based on how others to react rather than based on what they really think (Lencioni).

Top performers leaving

Some companies try to keep their top performers and pressure them into staying. This response can create uncomfortable social pressure and cause the employee stay for the wrong reasons.

H told me he’ll have conversations with his manager where, while they highly value him, will talk about, “Where should H go next?” Does it make sense for him to join a nonprofit? Start a new company? Because his manager shows genuine investment in his growth, whether its with the org or not, he continues to stay on and want to learn from her.

Other companies, like BCG, accept that their top performers will stay for two years, and then leave and do something else. These companies that accept the high turnover rate are building a natural forcing mechanism for sustainability. Because they know that their top performers will only be contributing for two years, they must prepare themselves for long-term sustainability by putting structures in place, like documentation and training, to enable new employees to rapidly learn and contribute to the organization.

Deciding what to build

I’ve noticed making high-level decisions at a mid-stage company is trying. Prioritizing at a startup is easier, because you have less groups clamoring for your attention. But when marketing asks for more money for ad campaigns and the engineering team complains about how they’re overworked and need another developer — how do you know which ones to select and execute on?

One way is to draft a list of all these priorities and ask everyone to vote. This approach democratizes decision-making, which, if done too much, can lead to a company without a clear product drive.

Another way is to ask two questions. Everything boils down to numbers.

Question 1: What are the inputs?
For example, if you want a marketing campaign, do you need more money for Google ads (external) ? Do you need to a month of engineering time (internal)? Often people think about external costs, but forget about the cost of internal company resources, which are just as valuable.

Question 2: What are the outputs?
All businesses have 3 goals. So these inputs must be manipulated in some way to generate output into one or more of these company goals:

  • (1) Revenue
  • (2) Cost savings
  • (3) Market growth

Thus, the decision about what to build becomes simple. You make the decision based on the input/output ratio.

Troubleshooting OAuth

When I first started implementing OAuth, I thought it would be difficult, but I realized with all the libraries and documentation now a days, implementing would be very manageable. While I thought using libraries to help would speed up the implementation — in hindsight, implementing OAuth with rauth, a Python OAuth wrapper library, unnecessarily abstracted away both logic and understanding.

OAuth consists of 5 components:

  1. Present user to webpage
  2. Page redirect to facebook
  3. Get code
  4. Exchange code for an access token that you store
  5. Use that access token to access user data with API

The complications usually lie in the details. The common problems I ran into were:

1. This authorization code has already been used.
I was calling the authorization code twice, when I should have exchanged the code for an auth token and called the auth token twice.

2. Incorrect access token
I had already exchanged the code for a token with rauth, and was trying to do it manually:

def facebook_authorized():
  code = request.args.get('code')
  if not code:
    return redirect(url_for('index'))
  data = dict(code=code, redirect_uri=get_redirect_uri())

  # rauth request
  fb_session = get_facebook().get_auth_session(
    decoder=lambda x: json.loads(x.decode())
  me = fb_session.get('me?fields=id,email,name').json()

  # manual request
  res = requests.get('', params=token_params)
  access_token = res.content.access.token

To get the access code from rauth, I can use

access_token = fb_session.access_token



Documentation is better than StackOverflow
]With documentation, you can figure out the first principles by yourself and troubleshoot your specific use case. Sometimes, StackOverflow can shortcut this for you, but more often than not you’ll solve the symptom but not the problem.

Don’t overoptimize too early.
I made the mistake of abstracting my OAuth functions into classes and started running into errors — the abstracted data structures made it difficult to pinpoint what the problem actually was.

Understand principles before jumping to the code
Rather than copying and pasting coding that you don’t understand, first understand how it works manually (i.e. the 5 steps above) and try to replicate that yourself.