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?

YC Female Founders Conference

Important update: Despite my article all about being thoughtful/aware of gender issues in tech, I sometimes screw up too. Shanley made a different, but also very important version first (now included in line as well). Ok and while I’ve got your attention about that, you should go subscribe to Model View Culture.

Last Saturday I had the opportunity to attend the YCombinator Female Founders Conference. I was a little nervous going in. Some of my fears were true, and some weren’t.

On the whole, I’d say “it was okay,” and not because I’m damning with faint praise.

Half was great. Half the content was exciting. I learned some great lessons that would have been applicable to any founder, not just a female one. If you get a chance to go see Adora Cheung or Diane Greene talk, do! Adora was hilarious and they both had great lessons. The fundraising panel was informative. The attendees were also great. It was great that many of the attendees were technical. The highlight of my experience was walking around the venue talking to Julia Grace, Head of Engineering at Tindie. I could go on about that, but it’d be your typical conference recap. I should at some point, because I really enjoyed it!

Unfortunately, the content about being female made me pretty uncomfortable. Going in, I was worried the conference was a PR move because of the recent bad press. It did touch on that a bit, but that wasn’t a big deal. The bigger issue was that there was a definite lack of awareness. Most of my specific examples come from earlier on in the presentations, but I felt they echoed throughout.

Please bear in mind that this is not meant to be a critique of the people involved. It’s a critique of the ideas presented. I’m grateful that Jessica and the YC team took the time to organizer the conference and prompt these conversations.

1. It seems off that this was the “most oversubscribed YC event ever.”

There was a big push at the beginning of the conversation that this was the “most oversubscribed YC event ever.” Okay, fine. That just made me curious. Why aren’t these women applying to other YC events?

Was it that they needed a special invitation? If so, will YC follow up by making sure there’s a clear “invitation” to female founders for all events? Is it because they’re uncomfortable at the other events? If so, why? What will YC do to fix that?

I’m not sure what the reason is for each attendee. I haven’t been to Startup School. For me the decision to attend was timing, and all the controversy beforehand. I’m also morbidly fascinated by events about women in technology. Plus I hadn’t been to San Francisco in six months.

But for the other people I met, those didn’t seem to be the reasons. They seemed more curious about solving specific problems. I talked to a lot of people about their startup, and about help they needed with UX, etc.

Assuming that most attendees were like the ones I met, it seems off that they wouldn’t all also apply to other YC events. I’d love to see YC look further into that and find out why.

2. “Percentage of companies with at least one female founder.”

YCombinator’s female funding metric was “percentage of companies with at least one female founder.” I think this was a bit disingenuous.

Kevin Marks made a clearer version showing percentage of companies with at least one female founder vs. percentage with at least one male founder. He got his data from YC’s published information.

graph

That makes the numbers seem not so good.

Similarly, from Shanley Kane:

graph2

More concerning, was the lack of awareness about why this is the case. Jessica said in her talk “and we started with people who read Paul’s essays.” The implication that I got from the statement was “we started with people like Paul.” There seemed to be no concern around that – or awareness that it could be the cause of the graph above.

If you define your target market to be white male “hackers”, and reach out to white male “hackers”, it shouldn’t be surprising when you get white male “hackers.”

It’s one thing to do that to get started. It’s another thing to keep doing that after you’re viewed as a thought leader in an industry. For me, it’s an ethical issue. You might make more money initially by focusing on only one demographic, but what’s the long term implication? I’d bet that same targeting also plays into the why women don’t typically attend other YC events.

3. Co-found with your spouse.

Jessica had a big section at the beginning about confounding with a spouse, but it also came up throughout the discussions.

This freaked me out the most. It seemed to be another case of “people like me.” Jessica and Paul managed to cofound together. Then they funded YC companies with spouse cofounders. The data shown was 34.5% of female cofounders had cofounded with a spouse. I don’t have the data – but I’d say that number is far higher than female-founded companies in general. There didn’t seem to be awareness that that could be a YC bias, and wasn’t necessarily the best way to succeed.

Additionally, I don’t think “cofound with your spouse” sends a good message. Why am I doing that? Should I cofound with my spouse because no one else would respect me? Because my spouse can force people to take me seriously? Because my spouse is the only technical person I’ll know?

I’d rather get advice around cofound with someone you can work with. Cofound with someone who calls you on your bullshit. Cofound with someone who has complimentary skills. Being a spouse isn’t a qualification for being a good cofounder.

There are a ton of people in the world. I doubt that for most people confounding with a spouse is the right solution. Men rarely get the advice “hey go cofound with your spouse.” I’m not sure why that should be any different. I can’t think of a single good thing that this message sends.

I don’t want to cofound with Tom. He’d be a wonderful cofounder, but not for me.

4. “Being the quiet founder.”

Jessica also talked at length about being the quiet founder. I have nothing against that. There has been work discussing that women have to be better at self promoting. It’s not always best to work hard and assume someone will notice. So, I think it’s debatable.

What freaked me out wasn’t that Jessica wanted to be a quiet founder. It was that that I didn’t notice anyone mention Jessica on stage after. I loved reading Founders at Work. She’s really smart and has great input.

But in each of the anecdotes from other founders, I heard things like “and then Paul said X” or “and then PG X.” These weren’t from press people – they were from founders in the program. Why did Paul make so much more of an impression? Why didn’t Jessica’s advice stick out in their minds?

That’s not a flaw with the conference. It still makes me nervous. It scares me if Paul is the only one giving advice to the founders. It also scares me if the women just aren’t remember getting advice from another talented woman.

So?

So, I’d go to the event again. I wish the industry was far enough along that I was writing about clever lessons I learned and was coming back to apply. Unfortunately, it’s not. The YC Female Founders conference made me realize how far we still have to go.

 

A rant-y personal opinion: I hate when people say “Product Guy.”

Like the title says, this is my rant-y personal opinion. You’re free to disagree.

1) It’s awkwardly generic and doesn’t create a good impression.

Working on “Product” could mean you’re a PM, a designer, an engineer, or a bunch of other things I’m probably forgetting right now.

Sometimes people think of “Product” as being just PM, but that varies by company. At Kickstarter, we regularly refer to all of engineering, design, and pm as “Product,” especially as compared to our Community team.

If you want to really communicate what your job is to people in the industry, saying “I’m a Product Guy” doesn’t do it.

When you say “I’m a Product Guy.” I jump to two possible conclusions – neither good. The first is that you think you can do all of these jobs well (that’s arrogant, and you probably can’t). The other option is you really aren’t involved at all yet, and you’re looking to get into Product. Either way, I’m not impressed.

2) It makes me formal in contrast.

There is no female equivalent of guy. This comes up all the time. I’ll frequently say “you guys” as a gender neutral (even though it really isn’t).

Ladies is the corresponding term for gentlemen. It’s more formal. But no one says “I’m a Product Gentleman.”
Women is the corresponding term for men. It’s pretty neutral. No one says “I’m a Product Man.”

There is no female casual term. I would never say “I am a Product Chick” (ew) or “I am a Product Dudette” (ick).

You place me in an awkward place when you say “I’m a Product Guy.” It makes me feel far too serious when I say “I’m a Product Manager,” even though that’s just my job title. It makes me sound formal because of the contrast, even though I’m not a formal person.

I have plenty of friends who do this all the time. They are nice people, and probably have no idea that it drives me insane. I could try to work around this by coming up with things other than my title. I do sometimes – “I work in PM.” or “I do product things.” It’s definitely not the biggest issue to tackle.

But hey, maybe you should know that I still feel uncomfortable and cringe every time you introduce yourself as a “Product Guy.”

addendum: People did point out to me that “gal” could be an opposite. While perhaps this was once the case, “Gal” definitely isn’t used in casual conversation the same way “Guy” is.