I’m angry because I’m afraid.

You may have seen a few angry tweets from me earlier about how Github handled the situation with Julie Ann Horvath.

First, I was angry about Theresa Preston-Werner tying the situation to Kickstarter. That’s a personal issue. It’s upsetting for me, but that’s not what I want to write about.

Instead, I want to write about all the other women in technology that this impacts.

No one seems to be recognizing that this situation is scary. So, I’m bringing this up even though it’s a career risk for me. It’s a risk someone has to take, and no one wants to.

Every time I tweet gender, I go back through to make sure all the people who are “important” to me still follow me. (Hint: people with power over me. Heads of Product at interesting companies. VCs. I’m not too afraid that my friends are going to stop following me.)

I don’t want to spend my time writing about gender. I want to spend it doing Product Management and founding companies. But I’m afraid if I don’t write it, no one will, and we won’t get better. If you haven’t noticed yet: I always alternate my “gender” essays and my professional content ones.

The Github thing isn’t just about one set of facts. It’s about how this reaction makes other women in technology feel.

The Facts

I try to not make assumptions about situations I don’t understand. I try not to blame people. I try to avoid reading into things.

Github’s had some other issues. Take the Meritocracy rug. I know the general criticisms of meritocracy, but it’s not like I notice every rug in Kickstarter. I doubt a meritocracy rug would have bothered me if I worked there. I shared the story when they reflected & removed it, because I liked that they were responding to the community. Death by a thousand paper cuts sucks, but I’m not going to weigh in on another company’s paper cuts. (Unless someone asks me! Always happy to try to help!)

But – I am going to weigh in on things that send messages to women in tech as a whole.

Julie Ann leaving Github was VERY different from something like the rug. She already had a lot of respect & weight in the community. She’d been a strong advocate for “be female in tech and do awesome work, and it will be okay.” She was all about getting more women into our communities & supporting them, rather than focusing on problems.

I usually feel that way too – I think it’s important to talk about things – but also good to stay positive.

Julie Ann saying what she did was credible because of the reputation she’d built. Github immediately responding also gave the claims credence. It also seemed unsurprising given what others had heard. (I don’t know many within Github, but the general sentiment amongst folks I knew was there were issues).

I think she told the truth. But that isn’t all the matters.

The Perception

Regardless of the exact details of the facts, Julie Ann’s perception also matters. A lot. People internalize situations based on prior experience – this wasn’t made up out of nowhere. Something did happen – regardless of the exact details.

Github’s answer was upsetting because it felt like a “non-answer.”

It said “she messed up enough to need to leave, but it’s not a technical legal claim.” That’s.. ambiguous. It comes across as “something bad happened, but we’re going to pretend it didn’t to protect ourselves legally.”

It was particularly weak because Julie Ann already said the process was more about arbitration. She’d already said it wasn’t about finding out what happened. Github finally saying this felt expected, weak and cover-up-y.

I get that there’s a legal issue. They don’t want to be sued. That’s a hard line to walk. I bet their employees are writing anonymously because they were told not to comment publicly.

But, that answer isn’t reassuring for women in technology at all. What happens if (when) something like that happens to you? Will your company throw you under the bus to protect themselves legally? Will they try to discredit you, even while taking actions make it clear something happened?

That’s ambiguous and scary. Seems like you lose twice – something bad happens, and you get discredited! Why risk that?

Then that got amplified.

The situation started feeling much worse when Marc Andreesen tweeted his support.. I’ve always looked up to A16Z. I’ve respected the people I’ve met there. Ben Horowitz used female pronouns in his book!

Marc’s tweets still make me uncomfortable.

The entire situation reads: A male executive can do something that’s wrong/sexist. The company will want to cover itself legally, so it will discredit the claims. It’s hard to PROVE something was sexist. There’s always so much individual variation between people – so it’s easy to discredit. The company does realize something was wrong – so it forces the executive to resign. Yet, a prominent VC is still offering support and funding, with no context.

Without more information, this is even more terrifying! For some people, this would be reassuring. Marc has his founder’s backs! That’s great! That’s not necessarily how it feels for women who want to start companies.

Let’s say I want to start a company (I do!) Let’s say I was thinking about taking money from Marc and A16Z.

What if something bad happened to me? Another venture partner did something wrong? Another executive from a portfolio company?

Marc’s statements make me wary that he wouldn’t have my back in that situation. He’d have the other, male, founders.

Seems more that someone would try to discredit me, cover it up, and support the male founder instead.

Money from A16Z suddenly feels very risky – what if something went wrong? Normally, I’d just silently strike it off my list of places to approach in the future. Today, I’m writing.

It isn’t just me.

We wonder why we don’t have women in tech – yet we don’t address when we terrify them! We focus on the facts instead of the overall climate.

Instead of thinking about what this situation means for all the women in tech, we focus on what it means for one founder.

I bet a bunch of talented women are writing off Github and A16Z as places to work and/or get funding right now because of this fear. I’d need to know far more to feel safe working with either of those places.*

As an industry we should and must care about facts. But we also need to care about the messages we send. Right now, the industry is telling me “if anything bad happens to you, we’ll throw you out instead of trying to address it.”

That’s what’s scary. That’s why I’m angry.

* I also know this isn’t just me. I’ve had women reach out today to share the same sentiments, who don’t necessarily want to share them publicly.

Some news: HBS

I applied to the Harvard Business School in the interest of “keeping my options open,” back in 2009. At the time, I didn’t intend to go (more on that in another essay).

That’s given me five years to think about it. There aren’t many decisions you consider for five years. In those five years, I’ve had at least 500 conversations. Thank you, everyone who talked to me.

People that I’d never met answered my emails, and agreed to talk with me about the decision. I’ve heard lots of strong, valid opinions for why I should go. I’ve also heard strong, valid opinions for why I shouldn’t. I’d even dare to say that I’m the world expert on “should an Engineer with two years of work experience at a large company and two years at a startup get their MBA?”

I’m so tired of thinking about it.

When I started having the conversations, I was searching for “the right answer.” There isn’t a right answer, but there is a right answer for me. I’m going.

The Long Run

In some fields, you go get an MBA to get to the next level. You put in your two years in consulting/banking, do the MBA, and then go back to the field. Some people to do it to my career switch to another discipline.

Tech isn’t like that. You don’t need an MBA in tech. It can hurt you. In two years, I’ll be seen as less qualified to do what I’m doing now. That terrifies me. (Yes, I want to stay in tech). Talking with Anna Khan helped me realize that I’m okay with being seen as less qualified – because I won’t actually be less qualified.

But it’s not about what happens for me in two years – or even in five years. It’s about what’s going to happen over my entire career. One of the earlier discussions I had about HBS was with Jeff Teper. The thing that stuck with me was “It isn’t one thing that helped my career after going to HBS. It’s just that every single interaction I have is a tiny bit better, and it adds up over time.”

From the two weekends I’ve spent on campus, I can see how that happens. It pushes you to think about your communication and interaction a different way. I know I’m not always patient. I know I have strong emotional reactions to certain conflicts. HBS will help me hone those things in a different way than the workplace would, and that over my entire life, that will matter. For me, that’s worth investing two years.

I’m going to HBS for all the small things I’ll learn, that will add up over my career.

Breaking my mental model

When I went to Engineering school, I said I was going to “learn to think like an engineer, but not to be an engineer.” Like many things I said early in my career, I had no idea what it meant. My dad said it, and I thought it sounded good.

Yet, that’s exactly what I did. I’m not a great pure Electrical Engineer, or Computer Engineer, or Software Engineer. But, I do think like an engineer. Whenever I hear something, it’s a problem that I want to solve.

Thinking like an Engineer didn’t feel constraining to me at first. Since I wasn’t great at one type of engineering, I insisted that I was a generalist and became a PM. It was the job that let me be closest to all the other jobs. It seemed like a broad way of thinking about things – even with that engineering lens.

The thing is: I’m not a generalist anymore. The more I work, write, and teach, the more PM fills my life. I act like a PM in my personal life. I approach every problem in a PM way (research, gather all the inputs, analyze cost/benefits, prioritize, do).

PM has become my hammer, and every situation looks like something to be PM’d. I rely more and more on my existing tools. I want to try to think differently again, and re-generalize myself.

I’m going to HBS to learn how to think a different way. I want to learn to see new opportunities, not just problems to be fixed.

The Case Method

I’ve also thought a lot about if another MBA program would be better for me. I’ve always wanted to live abroad, so INSEAD was tempting. The obvious choice for people in tech is Stanford. That’s not what I want to do. It’s not “Harvard” – it’s about the case method.

I’ve participated in five case discussions now. I’m convinced the case method will teach me to make better products. In each of the cases I’ve been astounded about the details that I’ve missed, what resonates with other students, and how many ways there are to think about a problem.

The case method is designed to create empathy and perspective. You have 90 brilliant people in a room, and many share their best, distilled insights on the problem. You learn how many different ways there are to see an issue.

You could argue that the best way to learn to create products is just to make more products. In some ways, that’s true. But, when I do that I tend to make them the same way, and optimize my process. I don’t build each thing using different techniques. I’d argue that I learn more about creating products from my hobbies.

Hearing all the perspectives through the Case Method will give me lots of new ways to think about building things. It will give me new areas to explore. It will help me build empathy, which is one of the most important things for making great products.

I’m going to HBS because the Case Method will teach about building better products.

Starting Something

I cannot hold two Product visions in my head at the same time. I can’t think deeply about how to help people best Discover and support things on Kickstarter, and also about “what do I want to start?” Trying to do this would be a disservice to my idea, and to Kickstarter.

For a long time I felt guilty (I’m just not trying hard enough!) That’s not true. A conversation with Hunter Walk made me realize it is reasonable that I can’t do both at the same time. I’m human, and that’s my limit.

I love working on Kickstarter, but now is the right time to go do something else.

I was talking with Kene when that clicked. We were discussing the oft-asked question “do you want to be a PM in 10 years?” came up. I’d toyed with the idea of wanting to be “head of Product” somewhere.

We were talking through it when I finally realized why I don’t want to be a PM in 10 years.

Being a PM means that you’re fulfilling someone else’s vision. As much as I love Kickstarter, and I feel a great sense of ownership over my work, Kickstarter isn’t mine. Kickstarter is Perry’s, and Yancey’s, and Charles’. I love the work I do at Kickstarter, but it’s for their vision.

I want to do my thing. There’s no reason to wait to do that.

I could definitely do my own thing somewhere other than HBS. Eric Stromberg pointed out “well couldn’t you go to Mexico for a month and figure that out?” I could, but I don’t want to. I like having structure, spontaneous inputs to my thought process, and lots of people to bounce ideas off of. That’s an environment I tend to thrive in.

I’m going to HBS because it will give me both the space and the structure that I need to figure out my own direction.

I don’t know where I’ll be in 20 years

When I look back five years, I’ve fulfilled my “five year plan” – but it definitely didn’t feel like that when I was doing it. It felt chaotic and messy and coincidental that I ended up here.

I have no idea what I’ll be doing in 2 years, or 20 years. I hope it’s just as messy and chaotic.

I’m going to HBS because I know I’d always be “what-if-ing” myself if I didn’t go.

A note on cost, and a few things that didn’t make this list

For many, the decision about HBS has a substantial financial component. It’s conspicuously absent from writing. I’m lucky in that my family has always been emotionally and financially supportive of my education. I’ve made this decision based on what I think is best for me, and not about a fiscal analysis of “payoff.”

Having “Harvard” on your resume does open doors. While I hope that someday everyone recognizes “Olin” that isn’t the case yet. While it isn’t a substantial factor in my decision, it does matter.

I also didn’t talk through the skills of the curriculum. I’m not passionate about learning accounting, but I do like learning. For me going to HBS isn’t about learning facts – it’s about learning how to be, and how to make.

photo (10)

Stuff I’ve Messed Up While Interviewing

One of the things on my mind recently has been interviewing. We’re hiring for Product at Kickstarter, and I want to make sure I give people the best chance to succeed. (Interested? Please reach out on Twitter or via email!) I’ve also been talking with people who are trying to get their first job in Product. That culminated when I taught “How to Interview for PM” for Startup Institute last Monday.

As I’ve talked with people, I’ve found myself sharing a lot more “bad” interview moments than “good” ones.

It’s important to realize that one bad interview doesn’t mean you’ll never get a job. It might just mean you aren’t a good fit for that company, or that you didn’t prepare well enough.

I’ve had some terrible interview moments. These are the most embarrassing ones. I’m going to share a few specific interview questions for the sake of the stories, but that isn’t the point. My goal isn’t to “out” the questions that any company uses. You shouldn’t just try to memorize specific questions. I’m using these examples to show how to avoid making the same mistakes I did.

I also put a summary checklist of how to avoid these pitfalls at the bottom.

Fall 2005, Princeton – “Do you have any questions?”

I think this was the first interview I ever had. I’d jumped through all the paperwork hurdles and had an interview with a Princeton alum. No one had ever talked to me about proper interview technique.

We had an awkward conversation about Eating Clubs (I am a dork, didn’t care). We talked some about gender differences (Again, cared about robots, not gender). The interviewer and I were definitely different people.

That could have been fine.

The death knell was when we got to the end and she said “do you have any questions for me?” and I said “no.”

Nothing signals a lack of interest/research preparation more than not having any questions.

This is going to come up at the end of every single interview. Most interviewers even say “and I’ll leave five minutes at the end for questions” before you start. The questions you ask will be the interviewer’s last impression of you.

Have a list of well prepared questions before you go into interview. You should care about the answers. I’d recommend at least two per interviewer. If you don’t have any questions, the company might not be the right fit for you.

Some ideas to get you started:

  • Things about the interviewer’s role in the company (how long have they been there, best part, worst part, how it’s changed over time).
  • Things about products (what they’re most proud of shipping, which project was the most challenging & why).
  • Things about the industry.
  • Things about the team (what are you looking for next while you build your team? What skills are lacking?)
  • Things about the company as a whole (what are the next challenges)

Spring 2008, Microsoft – “Give me 10 ways to improve an elevator.”

People have been talking about this question for a long time (here’s the Quora discussion).

I don’t want to talk about the nature of “design” questions, though. There are lots of better resources to learn about that. Plus, my struggle wasn’t there. I’d already gone through all the typical pieces of the question that are covered in the thread.

The PM interviewing me was pushing me for more practical implementation details. At the time, I wasn’t great at practical things, and he could tell. He also thought I might not have follow through.

He was right. I got tired of the question and started saying things like “fine. let’s add luggage racks. and drinking fountains.” rather than thinking critically.

I screwed up by not being resilient.

The interviewer called me on it, and (verbatim) said “are you fucking with me?” I still haven’t met anyone else who got told to stop fucking around in an interview.

It seems stupid that I need to say this, but I messed it up. You should NEVER give up on a question mid-interview. Some questions are designed to test your endurance. Just keep working through them.

Fall 2009, Google – “Give me an example of real world iteration & recursion.”

This is the roughest interview I’ve ever had. I didn’t sleep the night before, but figured it wouldn’t matter much because it was only a half an hour phone screen. Usually those are softballs. This one wasn’t.

First, we talked about a Google product. I wanted to talk about Gmail (I used it daily) but the interviewer didn’t want to. Instead, we opted to talk about Google Docs. Unfortunately, the interviewer had been the Google Docs PM, and I’d only used it at a surface level. Every suggestion I made turned out to already be in the Product. Whoops.

If you’re going to talk about a Product, try to make sure you know it better than the interviewer does. For smaller companies, you should know the Product inside out. For bigger ones, try to know a few of their common & less common offerings inside out. Give yourself options for what to talk about.

Like I said, this was my roughest interview ever. After the Google Docs fiasco, we got to the single worst answer I’ve ever given.

The question was “Give me an example iteration & recursion in the real world.”

I know what iteration and recursion are in code. I had no idea how to translate that, on the spot, into real life examples. For what it’s worth, while writing, I found this cool academic article on it.

We stumbled around for awhile before I told the interviewer I just didn’t know. She tried to help, but it was beyond repair. It was awkward.

I’m not sure I ever would have gotten that particular question. It was my fault for not being more prepared. Google is known for having particularly technical PMs. I was expecting to coast on having an Electrical & Computer Engineering degree. Unfortunately, ECE definitely isn’t CS. I should have spent more time preparing for those types of technical questions.

Years later, I interviewed with a company that was known to be more business/revenue focused. The interviewer asked how I’d calculate Lifetime Value for a customer. I’d never had to do it before, and stumbled around with trying to figure it out. Similarly, I should have been prepared.

Figure out what the company you’re interviewing cares about. Know what disciplines the PM is expected to be familiar with it. Figure out how to answer interview questions for those disciplines, too.

(NB: When Google recruiters reach out to me now, they always say “we see you interviewed in 2009.” That forces me to reflect on the horribleness of the interview all over again. Some advice for Google recruiters: making me feel bad about myself doesn’t make me want to work for you.)

Winter 2011, Decide.com – “How would you improve our product?”

In the Winter of 2011, I reached out to Kate Matsudaira for some unrelated career advice. We had a great talk over coffee, and she invited me to interview for a PM role at Decide.com. I was super excited about idea of working with Kate, and curious about being at a smaller company, so I jumped at the chance.

In my excitement, I neglected to notice that I hate comparison shopping. I’d much rather spend $20 more than spend an hour comparing. I also don’t put much stock in Product reviews. I’d rather just get one recommendation from a friend and go with that. I hate overanalyzing purchases. More often than not, I buy the first thing from the Amazon results.

Decide.com was a product to do exactly that I never would have used.

I’d never prepared a lists of recommendations before an interview. Ideas for what I wanted to do with the Product always came naturally. Given I didn’t use products like Decide, I should have made a list. (I always make a list now, regardless of the company).

Because I didn’t do that, I struggled to come up with product recommendations during my first interview. It was uncomfortable.

That set me up on a bad path for the rest of the day. I was anxious, realized things weren’t going well, and had trouble focusing. When Kate asked me a neat interview question (which I’m not going to share!) I didn’t do as well as I would have liked – because I was so nervous from my previous experiences.

Do your preparation work for Product interviews – especially if you wouldn’t use the product.

Fall 2012, Kickstarter – “How do you feel about psychology?”

I wrote a bunch about interviewing for Kickstarter over here. The most stressful of the interviews was definitely when I talked to Perry, our CEO. I was more anxious than usual because I was getting to talk to Perry, and Perry is way cooler than I am.

Perry threw me curve ball questions. He wanted to talk about psychology. I kept trying to switch the topic to something I was comfortable with – design or organizational behavior. Perry kept us on the psychology conversation.

This didn’t end up going wrong, but it could have. If I’d had this interview a year earlier in my career, it would have messed up the entire rest of my day. I would have agonized over why he’d asked me that, if I had the right skills, etc. This luckily happened late enough in my interview process for me to just move on and hope it worked out.

Be ready to just have a conversation if that’s how the interview works out. Don’t overanalyze or let it throw you off.

Fall 2013, Spark Capital – “Have you made any friends?”

Late last year, a recruiter reached out to me about an Associate opportunity at Spark Capital. I’d never considered a career in VC, but it seemed intriguing. I went through the interview process, and I’m glad I did. I learned a lot about myself, and I’ll write more on that later.

The question that turned me into a babbling buffoon was “have you made any friends since moving to NYC?”

Product interviews are more removed – design this, how do you feel about X product. No one had ever asked me about myself in such an intrusive way during an interview. It didn’t help that I’m anxious about meeting people.

I should have realized that VC interviews might be different than Product interviews. I understood that the “content” would be different (I prepped to talk about different categories of products, business models, etc). I just didn’t get that there might be an entire extra dimension about “me” and not “my work.”

Don’t make assumptions about a new type of interview based off of what you’ve done before. Figure out what the standards are in your field.

So here’s my checklist for prepping for Product interviews:

  1. Know the expectations for the industry, if it isn’t what you’ve interviewed for before.
  2. Know the Product(s) inside out.
  3. Genuinely care about their product, and do extra prep if you don’t.
  4. Prepare Product recommendations.
  5. Know which way their PMs lean – do you need dev chops? Business? Design? Be ready to answer questions that are from the adjacent discipline.
  6. Stick with it. Never give up during the interview.
  7. Don’t let curve ball questions throw off later interviews.
  8. If something does throw you off, rebound.
  9. Have two different follow-up questions prepared for each interviewer.

Portraying Women in Product Management

I’m sick of how we portray women in Product Management.

From the New York Times:

“Women often take on the role of product manager, or P.M., which entails the so-called soft skills of managing people and bridging the business and engineering divide. Yet even though this is an essential job, it’s the purely technical people — not the businesspeople — who get the respect in the tech industry.”*

We don’t celebrate women going into Product Management. Instead, we couch it as “well women don’t feel comfortable going into pure technology.” We emphasize that “the role is full of soft skills.” We discuses how it’s “non-threatening,” for developers to have female PMs. Then we assert that “pure technologists are the ones with all the respect.”

We never say “PMs are like mini-CEOs” while talking about women in PM.

When we talk about men going into Product Management it’s framed in a completely different light. “He wanted more scope.” “He wanted more control over the direction.” We fit the role into masculine traits of leadership and control. We view it as a step towards company leadership. The media rarely, if ever, applies those traits to women in PM.

That’s problematic.

What’s more harmful is where we take that logic. We start looking is at Product Management as a reason that we don’t have enough women in Engineering. The women in PM must have wanted to be engineers and then got stuck in Product Management! That isn’t true, and it’s downright insulting to women who are in PM.

It isn’t easy to become a PM.

First of all, it isn’t easy to become a PM. There are far fewer PM jobs in the industry. The ratio of PM:Engineering is usually from 1:2 on the super high end (Microsoft) down to 1:10+ many other places. There just aren’t that many of these jobs.

It’s also hard to get one. There’s a lot of specific subject matter you need to learn. You don’t learn to be a PM in school. Most PMs already went through the work of getting an engineering degree. On top of that, they combed through books, essays, and countless Quora answers.

You also need to learn a lot of specific subject matter to get a good PM job. When you prep for PM interviews, you want to know the product as well as the person interviewing does. When they’ve worked on it for years, that’s near-impossible. I tend to put at least a week into prepping for a full day PM interview. Getting my current job took six months, 10 interviews, and I wrote a full spec.

You don’t end up as a PM by “mistake.” You end up as a PM because you did a ton of work.

On top of that, you also do a bunch of extra work just because you’re a woman. The media keeps talking about PM is a role of “soft skills!” and “coordination!” That sounds like being an event organizer, and that’s not what a PM is.

In PM, you negotiate and persuade people without having any actual power. If you think about most of the media’s current discussions about women in management, they also apply to the PM role. If you’re assertive about what we need to build, are you bitchy? If you react strongly to a proposed feature cut, are you emotional or passionate? It’s a precarious balance. During my career, I’ve gotten feedback that comparable male peers didn’t get.

Women work just as hard to get into PM, and then work harder to get respect and stay in their roles. Assuming women are PMs because they “didn’t try hard enough” is insulting. Instead, we should be celebrating that we have a key role that seems to have a healthy mix of men and women.

Women PMs should focus on moving to Engineering.

On top of that, the subtle insinuation under this piece is that the women who ended up in PM are the ones who “should have” been engineers. Blaming the PM discipline for our lack of female engineers is flawed.

Being a great PM and being a great Engineer do not need the same skill sets. Engineers spend their time solving problems and figuring out how to make something happen. Product Managers spend their time figuring out what the user needs and how to balance that need with any others. Engineers tend to get to focus on fewer projects, but Product Management can end up being reactionary.

Take the Kickstarter office. If you’d come into the office a year ago with the simplistic logic that female PMs should be engineers, I would have been your “best bet.” I’m on the PM team. I have an Engineering degree, I write “Engineer” on my customs forms**, and I did a cute hack week project that involved writing code.

We did move a woman to the engineering team this year – and – surprise! It wasn’t me. It was Emily, who shared her experience over here. Emily has a different skill set from mine. She likes solving the technical implementation details of a project. She doesn’t want to decide how it should be – she wants to build it. She’s going to be a great engineer.

We’re blaming the wrong people.

Let’s stop implying that the women in PM are the reason we don’t have Women in Engineering.

I’m tired of people implying that my job is somehow lady-person “soft skills.” I’m sick of feeling like I have to defend my choice to be a PM over an engineer, when my male friends never do. I’m sick of the media subtly implying that the women we need to get into engineering jobs are the ones that are already PMs. It makes me feel like I’ve failed, even though no one else would say that’s true.

We have better places to focus than on “why women end up in PM.”

Quantitatively: Most women are doing jobs that aren’t Product Management. Numbers-wise, we’re better off recruiting those women to be Engineers.
Qualitatively: the skill sets of PM/Engineering aren’t the same. Let’s find some women who like puzzles, focusing on details, and implementing solutions.
Financially: Product Managers already have a comparable salary to engineers. We’re not going to help any salary gap issues by moving Product Managers.

Let’s stop pondering “why we have so many women PMs” and instead make engineering accessible to everyone.

* This is a very small piece of the article. The rest of the article makes a ton of good points. I’ve just noticed a similar trend across tech pieces, and I’m sick of it. I felt similarly while reading Kate Losse’s The Boy Kings.
** Thanks Jeff Hawkins!

Know The Rules Before You Break Them

Last Thursday evening Ashe Dryden tweeted about how tech fails to learn from the industries that came before us. You can see her discussion hereThat’s frustrated me for a long time, and her tweets resonated. This writing should help start a conversation, not finish one. In it, I use the word “rule” lightly. In some cases, it might be a governance structure. In others, it might be a standard or best practice. Also I know this is super long – so there’s a TL;DR at the bottom.

I love rules.

I hate following rules. I love learning from rules. Rules give you a way to learn from someone else’s mistake, twice.

First, you can learn why the rule was needed. Rules aren’t created for fun. They’re created because there was a problem. When you look at the rule, try to figure out what underlying problem led to the rule.

For example, why did big software companies come up with things like specification documents? Specs started to help reduce churn and make better use of developer time.

You can take at least two things away from that:

- Churn was a problem (people changing their minds).
- Developer time is a valuable, optimizable commodity.

Second, you can learn why the rule isn’t optimal. Most rules aren’t perfect.

What sucks about specs? Spec writing takes a ton of time.

If you only think as far as “specs taking too long” you’d go back to “no specs!”

You’ll have the same problem that others did: wasting developer time.

instead you can look at the reason the rule exists, and the problems with it. That might lead you to realize that you don’t need an entire specification document. You might only need to define a goal & success metric ahead of time to reduce churn.

Within the tech industry, we’re great at doing this… sometimes.

The example I used in the first section is trivial. Of course it make sense to look at existing standards.

In tech, we’re great doing it for certain things.

Most Software Engineers are quick to tell you that the best way to learn is Googling for what you’re trying to do. “Best way to X in Ruby” “Best way to Y in Python.” We collectively realize that someone else already tried to do what we want, and we make tweaks from there.

Even better, this doesn’t just happen for individual decisions. We have the same sorts of conversations around what architecture and tools to start projects or companies with.

Yet as soon as we get outside of specific “how we write code” issues, we start to flounder.

The longer I work in tech, the more I’ve noticed we don’t take the same approach when trying to learn outside of writing software.

I’ve met many startup PMs who tell me that “specs are inefficient,” but have never written a spec (or even seen a good one). I’ve had many people tell me “management is bad,” but have plan for their career trajectory.

We make these blanket statements based on our intuition. We remember a PM who wrote useless specs, or a manager we hated. I’ve been guilty of this too.

I have a few theories about why we do this, and how we can get better. To make this more tangible, I’ve tied an example to each of my theories.

1) We forget that we don’t know the rules (Management).

Most of the time, our jobs are iterative. If you’re a developer, doing a new project calls on many of the skills you already have. Same thing if you’re a Product Manager: learning something new also calls on the skills you already have. You’re learning, but you have an existing knowledge base to build on.

It’s easy to search for the existing “best answer” when you already have a knowledge base. You have an idea of what makes sense and doesn’t. You know what names are respected in your field.

Unfortunately, that method doesn’t work when you’re just starting out. It still helps, but you need more resources to give you a foundation. That’s true for engineering too – you don’t just start out one day googling “how to write X in Ruby.” You might try Codeacademy, or get a book, or ask a friend. Googling becomes more helpful as you work. That was just a long time ago for most of us. I think Luke’s piece explaining how he went about learning Python shows this pattern.

When someone starts running a company or organization, they’re in the same boat. Just like a beginning developer, they don’t have a framework to build on.

They don’t have a theoretical background in Organizational Behavior. They might not even know that OB is a discipline. They definitely won’t know nuances of the field. They won’t realize they can have separate strategies for OB (solving problems) and Positive OB (helping employees to thrive).

At the beginning, that’s fine! You don’t need to be an expert in every topic to found a company. It will be fine for you and your co-founder. It will be fine for more people after that!

But on top of that, we repeat a dangerous narrative. We tell founders that “everyone feels like they can’t do it” and “fake it ’til you make it.”

Saying that is a great way to help address impostor syndrome. It’s also good advice when the decision is too complicated for anyone to know.

It’s terrible advice when it’s a discipline we have years of study and experimentation on.

The combination of (1) things working at the beginning, and (2) a running narrative of “fake it” lures founders into believing they know more than they do. That in turn creates confidence they can keep going the same way.

They can’t. They haven’t learned the rules, or the problems with the rules. If all goes well, they’ll get to the scale where they need those rules too.

That’s when you end up with situations like the recent situations at Github  and Valve.

Spending more time thinking about why complicated management structures exist could have helped. Diving into the academic side of things from other disciplines could have, too. Since those incidents have happened, people have been sharing the Tyranny of Structurelessness essay. It existed before, and was known in communities that care about these issues. Doing research could have surfaced it.

So how can we do better?

When you don’t know, just admit you don’t know. Don’t fake it. You don’t have to solve every problem right away, but remind yourself that you don’t know everything.

Plus, you can end up with cooler things when you bother to do the research. You end up with novel ideas and organizations that look more like Spotify.

Spotify combined two traditional engineering frameworks that already exist. The combined a strict agile/scrum method with a Matrix organization to come up with their own hybrid.

You can learn a lot more about from this video. It has the advantage of giving individuals a lot of autonomy, while maintaining a firm management structure. Instead of starting from scratch, it builds on top of existing knowledge about management. We’ll be able to create better management cultures by paying attention to what already exists.

2) We care more about who said it, than what was said (How to Work).

Tech has also taken to adopting that there are certain people who “know” rather than doing rigorous research. Instead of analyzing patterns over time, we just gravitate to whatever latest Wunderkind says.

We try to claim this is efficient, but most of the time, it’s just lazy.

This comes up a lot when we’re talking about how to get work done. What hours should we work? How many hours should we work? Should we be alone or with other people?

For me, the example that always stands out in this category is how we treat interruptions and individual time.

At Microsoft, almost everyone has their own office. Because Microsoft isn’t cool, the general reaction is: “Well that’s why Microsoft sucks at innovation. No one can collaborate.”

Cooler companies, like Google, started switching to open office plans. Without research, everyone explained how this increases collaboration and improves how much gets done.

Open Office plans weren’t a new idea. That idea has been hanging around since the 1950s, and isn’t so novel. The New Yorker did a great piece on that history.

Yet we kept doing the same thing because “the cool places are doing it!”

That sentiment continued until other “cool people” told us it might be wrong. Now when people talk about personal space and the need to avoid interruptions, they cite Paul Graham’s Maker Time. Ironically, these are often the same people who criticized Microsoft’s individual offices to begin with. (As time has gone on, academic work on this also continues. Here’s another recent study about why it’s not ideal.)

Of course, “having uninterrupted time” and “having an office” aren’t exactly the same. At the core, though, both are trying to solve the problem of unwanted interruptions.

Another example that comes to mind is the number of hours we work. The factory “9-5” day started for a reason. We have many studies showing us that working long hours isn’t productive. Yet we’re also drawn to sexy startup cultures that do involve employees working all the time. We’d be well served to do more research into both of these phenomena before decided which is “better.”

We can be better at getting our work done. We just need to think about the lessons we’re trying to optimize for, and less about who is telling us those lessons.

3) We struggle with ambiguity (Diversity)

The reason a lot of people become engineers is that it feels like solving a puzzle. Getting to a tidy, correct answer is a wonderful feeling. Unfortunately, outside of engineering, lots of things aren’t tidy or simple. Because of our engineering experiences, we still want to create simple tidy answers in other realms, too.

The problem is that most of the time there isn’t a right answer.

This hits the hardest for me in diversity issues.

I’ve had a million conversations about “well what does success look like?” Unfortunately there isn’t magic success criteria. It’s not “as soon as 50% of engineers are female” or “when demographics represent the racial breakdown of the country.” Even if that was the case, those people might be treated less well.

Diversity is, and will continue as, a messy work in progress. Ashe wrote in more depth about (the lack of) success metrics for diversity.

It’s not that people who do other types of work don’t want a “best answer.” It’s just that there’s less likely to be one. It’s frustrating when we try to push for a “best answer” in places that one doesn’t exist.

Acknowledging other disciplines as having broader, messier answers will help us make more progress. Searching for a mythical “best” that doesn’t exist, won’t.

So, TL;DR?

Rules help us learn. We need to learn from why they were created, and from how they fail us to take the best advantage of them.

We’re great at thinking about rules while developing software, but we need to think about them outside of our core competency, too.

In order to do that, we need to stop making a few mistakes.

  • We must acknowledge when we have no idea what we’re talking about.
  • We should focus on content rather than sources.
  • We must understand that not everything has a “right answer” the same way our core work does.

 

On Better Gender & Tech Conversations

Talking about gender and technology can be scary. I put up these essays and then live in fear of being flamed. I also realize men worry about bringing these topics up. This (hopefully) provides a baseline that makes it easier to start good discussions.

Three baseline assumptions to start from:

1) Gender Bias is systemic.

We know that there are less women in technology. There are two possible underlying reasons for this:

  • Women are somehow “less good” or “less qualified.”
  • There is some sort of systematic bias keeping women out of technology.

There isn’t an answer between those two. When I say “hey, there’s a systematic bias” and you try to justify why there might not be, you’re saying “hey, you could just be less good!”

Think twice about what you’re going to say, and how you say it.

2) Women start the conversation feeling like they need to justify belonging.

There’s a bunch of things that happen to women in tech that don’t happen to men.

On the “light” side are things that have happened to everyone:

  • Oh, are you the recruiter? Do you work in PR?
  • Are you here with your boyfriend/husband?
  • You work where? Oh, they must have needed a woman.

The prevalent attitude behind these things is “you don’t belong here.” When women start a conversation about gender and technology, they’ve already had these experiences.

When you’ve heard those things enough, it’s hard to start from a blank slate. You tend to from the defensive place of “yes I belong.” Realize when you’re talking to a technical woman that she may already be starting from a bad place. That’s despite her best intentions. Try to help make that better.

On the heavier side is actual sexual harassment, and even assault that happens within our communities.

3) No one is saying it’s ~*~your~*~ fault.

Recently I learned that when I talk about gender and technology, my male friends feel like I’m blaming them as an individual. I am not!

The environment we live in is a system that’s been created over time. Individual actions do matter, but I’ve never once said “HEY YOU. ALL THIS GENDER TECH STUFF IS ~*~YOUR~*~ FAULT.”

(Nor do I know anyone else who has.)

I have tremendous respect for all the men I work and am friends with. If I see something that’s less than ideal, I tell them because I know they’d want to make the community better for everyone.

Sometimes, I point out incidents so we can all learn and be better prepared for next time. My goal is to help us avoid bad situations.

My goal is not to make even more people sad about this. I promise, I’m sad enough for all of us.

Some ways to be better:

1) Take feedback with the “most respectful possible interpretation.”

I learned this from a friend at Microsoft. I strive to do this for my work.

If I give you feedback, I hope you can believe it’s because I want things to be better! Please take it that way. I don’t enjoy making you sad. I also don’t expect everyone to go way out of their way to solve these problems. Everyone doing a little bit helps a ton.

A good example is how Ryan Hoover has handled my feedback.

A few months ago, I sent him a message about how few women were writing for Startup Edition. He replied immediately and gave me the power to write.

Afterwards, he went out of his way to invite me to contribute to Product Hunt, and featured me in their blog. When I mentioned there were still few female contributors, he agreed and noted it as an issue. He let me know when he added Cindy Wu to Product Hunt.

He watched the Female Founders Conference, found a takeaway, and wrote about it.

I was super nervous about how Ryan would take my initial feedback. I was afraid it might jeopardize my standing in his communities. To the contrary, we had an interesting discussion about it. Ryan wasn’t excluding women – he just didn’t happen to know as many. When approached he was happy to try to add more. He went above and beyond what I expected.

His positive reaction will make me feel more comfortable the next time I want to approach a community.

2) If you aren’t sure, ask.

I’m never offended if someone asks me an open question about something. There’s a chance my answer might be “hey I’m too tired to handle that right now.” That’s nothing personal – writing about this is exhausting.

Lots of great people have written “101” docs about some key issues to answer common questions. I particularly like Julie Pagano’s. I think asking is a great first step, but make sure the person you’re asking is open to it!

The key thing to remember when you’re asking is that this isn’t just an intellectual debate for women. It’s the life I live everyday. It’s not the sort of conversation that I can walk away from and move on with my life.

Chances are it’ll continue to impact me for a few days. Ask when you are curious and want to learn, not because you want to have a fun argument.

3) See something, say something.*

It’s frustrating to always be the one saying “hey gender and tech issue.”

It’s great when other people stand up and point out the issues, especially people who aren’t female. It gets tiring to be “that women”.

This has happened many times during my career. Most recently, a Kickstarter developer mentioned the Github situation during our all hands meeting. Before that, another coworker point out that there was only a “code cowboy” shirt and not a “code cowgirl” shirt.

Those are both great examples of saying something. If something seems off, point it out.

* Realized after I posted this that the reason this particular language was in my head was because of Julie Ann Horvath’s tweet that used these words: https://twitter.com/nrrrdcore/status/445401720374312960

Dear PM Recruiters,

The average job description on your website always seems to be:

“We’re looking for an enthusiastic, experienced Product Manager with 3-5+ (or 5-10+!) years experience in the consumer web startup space. Prefer experience with search/browse, discovery, or e-commerce. International and social experience a plus. MBA from top program okay. Prefer technical undergraduate work. Must have proven track record of delivering products.”

This job description is the PM equivalent of “must have 10+ years of iOS development” (riiiiight) or “unicorn designer who can do everything from experience to visual details and code.”

These qualifications are near impossible to get. I don’t have them. I can only assume they’re optional based on all the recruitment emails saying I’d be “perfect” for these roles. These qualifications also discourage lots of talented people I’ve talked to from applying to your job.

Since I’ve started working at Kickstarter, I’ve gotten about two of these per week. I don’t mind – I’m always happy people are interested and I like asking about opportunities. Bonus points if they do their homework (How About We does!) or if it’s an actual PM Manager instead of a recruiter. The thing is, I love working at Kickstarter. I’m not looking for a new role.

That’s our problem. It seems like all the PM recruiting goes into poaching the same people. People who work one of the currently popular startups, or Google/Facebook. You know, all the people who are happy with their current role.

It’s good to try to hire people who aren’t looking, but it’s also good to look outside of this “traditional” group of people. Since most of us don’t meet the ridiculous description anyway, let’s broaden the net.

Here’s two ways:

1) Hire from Microsoft

When I worked at Microsoft, no one tried to recruit me. The only conversation I had about another job was with Kate Matsudaira, and that was when I asked her for unrelated help.

Then, when I started interviewing to leave Microsoft, I got discouragement:

- “Seattle startups only want people who have more like four years of Microsoft experience”
- “Microsoft PM” is a different job from startup PM. (Spoiler alert: it’s not).
- Bad things about Microsoft and how it’s boring / stodgy / doesn’t know anything.
- Nothing.

That doesn’t just happen to me. I’ve talked to some friends who are (currently) looking for new roles about it.

Take for instance, Jon Bell’s tweet (Jon’s a designer, not a PM, but same idea):

ed note: Jon clarified that he actually meant 7-8 years ago, much earlier in his career. I’m leaving this in because it still inspired me :)

There’s a lot of Microsoft talent that no one ever bothers to try to recruit.

Many young people start out at Microsoft because Microsoft is phenomenal at recruiting. They also get offers on the table early. Especially if you have student loans, it’s a little crazy to not take the Microsoft offer. Even though Microsoft isn’t “sexy,” some of the best people still end up there. Plus, lots of those people aren’t intending to be lifers.

These people will be easier to hire than people already at exciting startups. The culture at Microsoft doesn’t lead to people discussing opportunities at other companies. They often won’t be thinking about their “next move” yet. Plus, they aren’t recruited as often. But you shouldn’t just be hiring them because it’s “easier.” There are also ways they can be “better.”

Why would you want a Microsoft PM over somebody else?

- They’re experts at execution. A ton of the PM job at Microsoft is project management and getting the software out the door, on time, and at a high enough quality. At startups founders often have lots of “vision.” You’re more likely to lack people who execute cleanly.
- They can help with process. As you grow, you’re going to need some process (yup. sorry.) Microsoft PMs have seen the impacts of good and bad process, and can help you avoid some mistakes.

How can you make sure your Microsoft PM will “fit”?

- They have any sort of side project/activity.* This shows that they have their own vision/ideas. This doesn’t even have to be a technical side project. Running the Awesome Foundation in Seattle informed much of the work I do now.
- They bulked up on other skills. Microsoft will pay for you to take graduate level work. Someone who took CS/Design at UW is interested in continuing to learn and expand their skills.
- They’re excited. They get excited about the work you’re doing – and have new ideas for it.

Stop tainting every individual employee with your “Microsoft” brush. Start looking for the ones that could add something to your company.

Did I convince you to consider Microsoft PMs? If you send me your role, I’d be happy to share it. (Or: Microsoft PM looking for a new role? Let me know and I’d be happy to share opportunities I find with you).

2) Hire from career accelerators.

I’ve been teaching at SINY for three seasons now. Each season, the class gets more qualified. Most of the Product Track students have held roles in art, design, program management, or project management.

Why would you want to hire these people?

- They’re brave. They all just said “my career path isn’t working, I’m going to use the data and try something else.” That’s the sort of person you want working on your product. They can call it like it is, and figure out next steps.
- They will work their butts off. They don’t have any of the entitlement a career PM might have. They’re new and hungry and have a lot to prove. They want to get the role, and if you give it to them, they won’t want to disappoint you.
- They’re comfortable asking for help and saying what they don’t know. They know that they’re new to the field and have a lot to learn! Many have reached out to me for extra conversations. They’re quick to realize when they don’t know something, find the appropriate person, and get help.

How can you check that they’re a fit?

- What were they doing before? Having had one role that was serious and at least adjacent will be good.
- How did they focus their learning? Which skills did they learn first? Why did they pick those? What do they want to learn next? The key thing I’d look for is making sure they’re interested in learning the technical side of things – not just a “cushy” role. It’s also a way to tell how they are at prioritizing, which is a key part of the PM role.

Interested in having a recruiting conversation with a Startup Institute NY student? Let me know and I’ll be happy to introduce you to some.

Conclusions

You can’t just keep trying to hire Unicorn PMs – there aren’t enough.

Microsoft PMs will have more of the “core skill set” and experience of going through the Product Process. You’ll have to work to find the ones that are excited and will thrive in your company.

Startup Accelerator PMs will be willing to work hard and ask questions to learn. They might not know everything yet, but they’re going to be great once they get there.

Figure out what’s really more important for your role, and recruit in that direction, too. It’ll be better for all of us.

Thanks,

Ellen

*This may be controversial, but isn’t meant to be. I don’t mean this in the “They should have a Github profile and contribute to OSS” way. Ashe has written about why that’s not a good way to hire.  This isn’t a perfect indicator. I would never disqualify someone who couldn’t do this because of financial/familial constraints. But, if I was talking to equally qualified candidates and one “liked to watch TV” and one “ran a side project” I’d probably opt for the side project one.

Some Advice for YCombinator

Yesterday Sam Altman (newly President of YCombinator) tweeted, asking for advice about women:

Personally, I prefer people ask for help. It may be naive, but no one is obligated to give them help. I am an eternal optimist, so I tend to respond. Given that, I sent Sam an email yesterday afternoon.

I’m not going to publish my entire email verbatim, but wanted to publicly share the suggestions that were in it. It is admittedly most of the email. I think these suggest apply to anyone in this space – not just YCombinator.

1. Hire someone to show that you’re investing in these issues, either on a temporary basis or full time.

It shows seriousness about solving the problem. Much the way I like accelerator programs indicating seriousness for an individual who is looking to make a change (hackerschool, startup institute, etc) – YCombinator hiring someone would show that it’s top of mind and important.

Secondly, this is a really hard problem. It’s not the sort of thing a little free advice from the internet solves. I’ve been thinking about it (and living it) for 8 years, and I’m far far from having all the answers. It’s the sort of issue that needs people who have the time to do good work and research.

2. Proactively listen & respond to the community that already exists (preferably in a non-defensive way).

I was at the YCFF Conference. I wrote about it. I raised some questions, and pointed out some things that weren’t uncomfortable to me. It wasn’t meant to be attacking or damning. I’ve talked to a bunch of people about it. I haven’t talked to anyone from YC about it. I’m unsure if it wasn’t seen – or if it wasn’t important. I don’t mind, because I write primarily for myself and those it helps. But it seems as though people who are taking the time to consider / respond to your organization are the type you’d want to be listening to, and reaching out to. I feel rather sad that I’m writing this, after I already wrote a bunch trying to explain things.

The only article I saw that was responded to was this one.

Unfortunately, the main response was that her comment about Alexis was incorrect. I fully agree that Alexis is a proud nontechnical founder, but that wasn’t really the point of her piece. Her piece has a ton of great points, and it stuck me very negatively that Paul and Alexis would bother to respond to that one piece defensively, rather than looking for a way to learn & benefit.

3. Be extremely self-aware in your personal thoughts/actions.

I don’t want to hammer on you for one incident because I’m sure you’ve already gotten that enough. That said, a defining point for me in if my managers/mentors in tech have been people I want to be around, is how personally aware they are of gender/tech issues.

If you want to be a leader and make YC seem approachable for female founders, it needs to be something you think about personally too.

(For the record, I’m not saying you do this ALL THE TIME or something like that – just that it’s something you need to be even more aware of as a leader).

From this blog: “Lots of other signs point to a bubble—founders of Series A stage companies being angel investors, a significant uptick in the number of parties, hot girls roaming bars trying to chat with any guy that looks like he might be an engineer and looking for a job, soaring rents, soaring salaries, lots of new investors coming to valley, and MBAs starting companies as the fashionable thing to do again.”

4. Go out of your way to recruit.

Like it or not, there is already a reputation that YCombinator isn’t funding female entrepreneurs. You have to overcome that perception. I’d go out of your way to reach out to people. I do get contacted by Heads of Product. Female engineers get contacted too.

Figure out who you think would be a great founder, and personally ask them to apply or get them thinking about it. Have meetings with them even if they aren’t sure. If you aren’t sure who to ask, ask other people who would know. You got “enough” people from an initial set who read Paul’s essays/hang out on HackerNews, but that doesn’t mean that’s the best possible set. Just because it’s “enough” doesn’t mean there isn’t recruitment to be done.

Conclusions

Sam answered me shortly after I sent him email (which is good! thanks!) I’m not publishing his email because that seems like a shitty thing to do with personal correspondence. I did realize after I sent my initial message that I left out what’s effectively “point 0” in this conversation.

0. We need to collectively acknowledge that this is a problem in our industry. We need to care about fixing it, because fixing it is the right thing to do.

I’m also going to stop writing about YCombinator now, because I’d really rather be writing about Product Management.

How I got a job at Kickstarter (in 6 months and many steps)

Once upon a time, I decided I wanted to work at Kickstarter. That became a reality after six months and a lot of not so easy steps. I find myself repeating the story often, so here it is (in writing!)

I found out that Kickstarter had a Product Manager opening when Diana Kimball tweeted about it on April 25, 2012.

 

I read the job posting.

Screen Shot 2014-03-18 at 8.26.18 AM

It was a weird lightning bolt moment. I was suddenly sure that it was what I wanted to do next. I near simultaneously decided I didn’t want to ask Diana for an introduction. Diana had helped me prep for my Microsoft interviews, and it seemed like asking for one too many favors.

Instead, I sat and waffled about how I could create the best possible application. I considered trying to be “creative” by making a photoshop mockup of a Kickstarter project page, but decided that would take too long.*

On April 27th, 2012 I finally sat down and put all my thoughts into a cover letter. Hitting “send” on that email was one of the highest emotions of my life.

I didn’t hear back from Kickstarter for a long time. I started getting nervous and disappointed that I’d have no way to get in the door. It made sense though – I assumed Kickstarter had bajillions of talented Product Managers applying. Ones who’d worked at places that sounded a lot cooler than Microsoft.

On May 22, 2012 the project for XOXO launched. I started seeing more and more of my friends back it (this was rare before I worked at Kickstarter!) and it seemed important to the company. After convincing Tom he also wanted to go, I backed the project on May 23, 2012.

For the most part I’d tried to put Kickstarter out of my mind. Then, on June 6th, I was standing at the 545 stop on Bellevue waiting for the bus to work. I pulled out my phone to check my email, and there was an email from Brett, Kickstarter’s Head of Product. I almost tackled Tom at the bus stop. Then I realized I shouldn’t talk about wanting another job in front of lots of Microsoft employees.

Between June 8th and 19th I had some typical PM phone screens. I prepped a little bit in my notebook about topics I thought were interesting for Kickstarter. I talked to Brett on the phone first, then he introduced me to Jed so we could chat. Shortly thereafter, I left for a vacation.

When I returned from vacation in mid-July, I got back in touch with Brett. He had the unfortunate news that there was no space for a PM. At the time, I wasn’t sure he was trying to nicely brush me off. It turned out that wasn’t true, and Daniella had moved from the community team. Regardless, Brett and I agreed to stay in touch about the role for the future.

On August 23rd I emailed Brett and mentioned that I’d be at XOXO. I was hoping to meet with anyone who’d be around. It turned out Brett would be there too, so we agreed to grab coffee Sunday morning during the event.

I’m not sure Sunday morning was the best choice, because it meant that I spent the first three days of XOXO, September 13-15th, as a nervous wreck. I dragged Tom away from the Kickstarter kiosk area. I refused to talk to anyone because networking scares me in general, and I was already anxious about the meeting. Plus, at that point, I’d quit my job and all my eggs were in one basket.

Finally, on September 16th Brett and I had Stumptown coffee and talked about Kickstarter. Later that day Brett introduced me to Charles. At the time, I had no idea that Kickstarter even had a design cofounder. I’d never heard of Charles. I was surprised when Brett introduced me to someone who definitely wasn’t Perry or Yancey.

Charles was fun to talk to. We stood behind a sheet in a hallway outside of XOXO. We talked about the role of user research, and the connection between PMs and designers. He invited me to continue our conversation after the end of the talks, but I had to catch a bus back to Seattle. I would have moved my bus ticket, but Tom and I were flying to Germany the next day.

I followed up with Brett. On September 19th I started doing a project to tackle changes I’d make to the Discovery experience. I still in Germany/London at the time, and wasn’t a good travel companion. I spent most of my time thinking about Kickstarter.

On September 29th I sent over my redesign of the Discovery Experience for them to review. You can see that over here. Consider yourself warned: it’s 22 pages.

I was in Prague on October 3rd when Brett invited me to fly out and visit Kickstarter. We arranged the time, and scheduled all day interviews for October 15th.

I cared a lot about having them go well, so I was really nervous.

It helped that I got to start by talking with Charles, who I’d already met. If I was ever scheduling interviews, I’d try to give the candidate a comfortable one first. It’s easier to talk to someone you’ve already met once. Charles and I talked a bunch more about user research.

Then I talked with Andrew, who asked me “what have you read recently?” That remains one of my favorite interview questions.

At the time, Kickstarter was working with a recruiter, so I talked to her for a bit.

Then, I had my only developer interview. At Microsoft, there’s usually a technical PM interview with softball code questions. Sam and I talked about my laptop stickers instead.

I had lunch with Brett. Brett also asked me the one of the questions I find the most intimidating – “how do you think it’s going?”

After lunch, I talked to Perry. That was definitely the most unusual PM interview I’ve had. We talked about psychology (pure psychology: not design, not organizational behavior).

After Perry, it was a big contrast to talk to Jed. He was the most methodical, and the one who focused on the work I’d actually done beforehand.

The last interview freaked me out. I was talking with Daniella. We only talked for half an hour when she decided we were done, and that seemed like a bad sign. Turns out we’d just gotten through all the questions she’d prepared.

Overall, I was feeling pretty good after my interviews, and had assumed they’d be the last step. I was surprised on October 17th when Brett asked for references. It was apparently a suggestion from the recruiter.

I provided a bunch of names on October 18th – a previous manager, a previous coworker, and a couple people who also ran organizations I was involved with. I held my breath, because it was the first time I’d needed references for a job.

Then on October 22nd I got my Kickstarter offer. I immediately invited Jeff and Eric over to play a celebratory game of Cards against Humanity.

After some negotiations, I signed my offer letter on October 26th and agreed to start work on December 4th. Everything since then is documented in my portfolio.

* In retrospect, I’m glad I didn’t do that.

What I learned about Product Management from ‘insert hobby here’

Alternate Title: Want to be a better PM? Have a hobby.

There’s been a plethora essays lately that fit this format: “What I learned about Product Management from <My Hobby>.”

The first one I saw was Steven Sinofsky on Product and Yoga. I logged into Medium to get a few more examples. The first one that came up was Mike Su’s piece on how a football coach framework applies to Product Management. It doesn’t fit the exact format, but it’s a similar idea.

When I first started seeing these pop up, I thought the specific hobbies mattered. Yoga could make someone better at Product Management – I wouldn’t make so many snap judgements! Of course a sports framework could apply to Product Management – they’re both types of strategies!

I spent a bit of time agonizing over “What’s the best hobby for getting better at my job?”

Then the essays starting getting a bit more ridiculous. My favorite is “What Product Managers can learn by playing Star Craft” from Thomas Schranz. (He also wrote one on what PMs can learn from Jiro Ono).

After my brief moment of “Maybe I need to learn how to play StarCraft…” something snapped. These essays are fun to read, but having any hobby outside of being a PM will help you be a better PM. Doing your own hobby to internalize lessons will matter more than reading 500 of these essays with other peoples lessons. It doesn’t matter what that hobby is.

Here’s a few of the most important things I think PMs can learn from hobbies:

1) Hobbies remind you how hard it is to learn something new.

My mom gets credit for teaching me this first, but I’ve reinforced it with my own hobbies.

When I was in high school my mom decided to take up the flute. She didn’t intend to play seriously, and it had nothing to do with everything else she did. It seemed way less practical than her previous hobby (photography).

When I asked her why, she said “It helps me be a better professor. My students have to learn new things everyday, and I never want to forget how challenging starting something new is.”

PMs need to know this too. You’re constantly explaining new ideas to people on your team. You change things for your customers and need to understand how they’ll react. You’ll mentor new PMs that join your team, especially if they’ve joined you from another discipline. You’ll need to explain your toolset to new hires. It’s important for PMs to remember how hard it is to learn something new.

It’s near impossible to do that by doing the same job. Overtime, things you do become reactionary. I just had my 100th Scuba Dive, and it was far easier than dive number one. Getting my regulator to face the right direction seemed impossible at first, and now I don’t even need to think about it.

Similarly, I used to have a more exhaustive framework for every Product decision I made. Now, I can often trust my intuition. That’s not a great way to explain to someone else “why we’re doing this.” Learning new things forces me to be more rigorous in my thought processes. Learning something new will make you be a better PM.

2) Hobbies help you see things from a different angle.

Hobbies can contrast what you do at work.

Product Management is an open ended job. There are lots of processes you can uses, but chances are you’ll be pulling bits and pieces together at different times. There’s no “checklist” that you can go through at work each day. Lots of your work will be open thinking, and lots will be reactionary.

For me, baking helps counteract that. In baking you have to follow the instructions, or things don’t typically turn out well. It gives me a chance to read all the instructions first, and then follow them as I go. Having a structured hobby helps remind me that there are good frameworks. It helps me make more structure for myself in my work.

Open-ended or structured isn’t the only contrast that a hobby can reveal. There’s lots of others. Engineering can be pragmatic, and an art-based hobby can be more idealistic. My product work tries to solve a problem, whereas my writing tries to express an idea.

Seeing things or doing work a new way will help you bring new techniques to your Product Management.

3) Hobbies give you time to think in the background.

I am anti “being busy.” I think it’s important to have time away from what you’re doing to sit and think. I think it also shows that you’re managing time well. I won’t get into that, but I think Scott Berkun describes it well in this essay.

Making the time to have a hobby means you have time to think in the background. I have a lot of my best insights while I’m not actively thinking about Product Management. I thought about this essay while Scuba Diving last week.

Having a hobby that engages my brain in a different way helps me much more than passively zoning out would. Reading, scuba diving, writing, and baking are all great examples of this. I have more insights from these types of divergent activities than I would watching TV.

What’ve you learned from your hobbies?