Product Q&A with Ellen Chisa
Ellen Chisa is the VP of Product of Lola. She is also a Product Advisor at Flybridge Capital and an instructor of Product Management and Interface Design at Franklin W. Olin College of Engineering. In her free time she likes to write, read, play pinball, and scuba dive.
About Lola: We're a new kind of travel company that provides on-demand, personal travel through a smartphone app. The Lola app instantly connects people to our team of travel consultants who find hotels, research vacation dreams, book flights and anything else our customers need. We also help while they're on their trips. In short, we take care of our members' every travel need.
On the web:
To join in on future Q&A, check out our Product Manager HQ community!
Select questions and answers from the AMA:
What are the first things you look at when you examine a startup?
Generally, I’m interested in…
- Founder-Team-Market fit. I think you should always have a unique advantage for what you’re going to work on. A great example of this is Pillpack – TJ (their CEO) and his family had worked in pharmacy and seen those challenges first hand. He knew the space, wasn’t just jumping in to “disrupt” something he didn’t know.
- How much I love the space. I’m always looking to work on things that I first-hand care about and think make the world better. Clearly, this matters more for taking a job vs. investing.
- How people on the team think about failure and learning. I’d much rather hear someone say “we messed up X and this is how we’ve changed as a result” than always being positive.
How do you spend most of your time these days and how has it changed over time?
Right now I spend a TON of time with people. This is hard for me as a natural introvert. I’d say nearly half my week is in 1:1s and small group meetings with my team, my peers, my manager (our CEO), and other people on engineering/product/design. My door is always open to anyone on our team, and now that it’s 50 people that’s quite a lot of people to talk to.
I use Sundays to do deep product thinking a lot of the time – where are we going next and why. I try to have about 2-3 big priorities each day. Yesterday that was translating some feedback from an advisor to our team, working on some key design challenges, and responding to some other customers who had sent us feedback, and doing some user interviews.
With this massive movement to VoiceUI – I am curious about your thoughts of how things will progress there, and what key things we should watch?
I’m fascinated by the current transitions to voice. About 18 months ago one of our advisors and I really disagreed here (he thought it was the future, I thought no one wanted to look silly talking to their watch/phone in public).
While I still believe it’s a little weird in public, I’ve really come around after products like the Echo. I have three in my house (one of each type) and I’m constantly frustrated when I travel and it’s not around to work with for simple questions. I think voice is best for quick interactions. The downside of voice is you can’t see “status” the way you can in a traditional UI. The device either needs to keep track of it, or you need to be able to just use it as an entry point to other experiences. I think it best models a good assistant – it figures out what you’re asking and gives a quick answer and sends you somewhere else if you need more.
What is your role as product advisor at Flybridge like? How does that differ from a “regular” product role?
Advisory roles are quite different from day-to-day operating roles. I’ve just started in the role so we’re still fleshing it out. It’s really a great way to be part of the community at Flybridge. I’m able to participate in other portfolio events and am around to give advice to teams on product, and/or to help vet the product strategy of teams they are considering. I think of it as being similar to some of the types of advice I’d give to friends/founders naturally, but more formalized.
What would you advise a first/second year university student if he/she wants to learn more about the PM field and be competitive?
- I’d say that early on in your career that’s a lot of benefit to diving deeper into one of the key disciplines. Once you’re in a full-time product role it can be hard to be an awesome engineer or an awesome designer – you’re just doing product. I sometimes wish I’d spent more time in one of the other roles first as it can be easier to go from one into product than the reverse. I’d figure out which discipline you want to double down on, and spend a lot of time there.
- Then, I think you can layer product work and learnings into that. If you’re at a project-based school, there’s a lot of great experience in helping your teams on those projects succeed.
- Get to know people. Everyone does PM differently! My advice will be different than anyone else who comes to do an AMA. It’s good to learn from people but realize that you need to separate substance from style. Figure out the substance of product, but be willing to define your own style.
I had a question, when is an engineering degree an advantage or a disadvantage for an aspiring PM?
Disadvantage – When you aren’t willing to let go of the technical details. At the beginning, it’s best to draw a hard line for yourself. You should NEVER be giving the solution. It can also mean that people try to drag you back closer to project management and corralling people. It’s important to set expectations with the engineering team for what you are able to do well, and what your scope is. I had to spend some time talking with all of the engineering leads to make it clear what I did/didn’t have the bandwidth for. It’s better to admit you can’t project manage everything and find someone else to do it vs. doing a bad job and having people think you aren’t able.
Advantage – It’s hard to articulate this fully, but you can often see things more clearly. You know what’s hard, you know what the tradeoffs are, and things just feel more intuitive. It’s easier to know who a bug goes to. It’s easier to remember who works on what part of the product, and what cascading ramifications of changes will be. I often don’t see these advantages until I work with some of my less technical teammates and realize some of the things that are natural for me aren’t for everyone. My favorite is also just the relationship. I think having the technical degree often means a more similar communication style, and some good bonding. Some of my best relationships at every job have been with engineers I work closely with.
What do you consider the essential technical skills for a product manager in the tech space?
This is so closely related to the last question! I think I only really have two…
- Ability to ask good technical questions – “why is this hard?” “what if we tried X instead?” “why did we make this technical decision?”
- Ability to query data – sometimes you get MixPanel and don’t need any skill, but sometimes you do need SQL. Depends on the role, but you need to be able to get at the data.
What are some learning/achievement milestones for the first few years for someone starting out in PM, after a few years in another role?
I love the answer I got from a mentor at Microsoft – as a new PM you either have “good starting skills” (big ideas, excitement, motivation, design) or “good finishing skills” (managing to resolve error cases, get that thing shipped, be really thorough). You’re a great PM when you can do both. I’d say in the first few years you should definitely move yourself towards being able to do both even if you’re stronger at one.
I also think it’s about looking at the scope of your projects. My first project was TINY, my second one was a little bigger… then at the next job my first project was small again, and continued going from there. That keeps going until you’re leading a team and you really worry about the whole thing. I’d make sure that you feel like you are continuing to grow that scope and you’ve moved into slightly more complex product areas.
How does one seek out PM mentors?
This one can be tricky. There are fewer PMs than there are in other roles, and then even fewer people who are “senior.” I’ve really focused on trying to learn from lots of different disciplines.
I don’t just talk to PMs – I try to learn about management from our VP of Member Services (she’s a really great manager) and our SVP of Engineering, for example. For finding PMs, I still think it’s best to meet people organically or casually and nurture relationships over time.
As someone with a strong engineering background but unable to get much biz experience in my current job, and aiming for product management, what would you recommend for next steps?
You have to decide what to learn next! I just wrote a ton about how I think about learning and I’d feel bad not giving it to you as a starting point.
That said, I think for business in particular it’s more thinking about which piece of business you need to learn. If you do B2B product, it might be about learning sales. In that case, I’d ask to sit in on some cold calls, and even find a sales mentor to let you do one for you – or find another organization – like a nonprofit doing fundraising – that would let you. If it’s strategy, I’d spend more time analyzing companies to figure out why they succeed/fail, and I’d recommend spending the $10/month to subscribe to Stratechery to read Ben’s thoughtful analysis of companies – that’s a great starting point. If it’s more of the marketing side, you’d want to take another approach, etc. “Biz” is very broad but hopefully this helps!
Have you ever worked with remote teams? Any cool ideas on getting team morale up, or general ideas to make remote better? What are your thoughts on product management consulting and remote product management?
I worked on a remote team when I was at Microsoft, and it was quite challenging. The biggest thing was to be sensitive to the needs of the remote office (for a place with headquarters). People often felt second-class, and reacted accordingly. That meant I overshared more than I might otherwise, solicited extra opinions, etc, to help everyone feel in the fold. I think making people not feel like the “other” is very key here. I think frequent travel helps. I was able to go to the remote office for about a week every month during the most intense part of our collaboration, and that really helped.
For Product management in particular, I don’t prefer to be remote (or hire remote people). As I mentioned before, about half my time is spend in 1-1 and small groups. I think that’s a lot harder to get done on a regular basis, and harder to get done in the “water cooler” type way when you’re remote. I personally would never hire a remote PM on my team. I might eat my words in a few years when technology is better, but for now, I’d rather hire and train someone who was here.
For Consulting, I’m a fan of people who can pull it off, like Jenn Vargas and Melissa Perri. It’s not my thing. I think the best part of product is being in the nitty-gritty everyday, and understanding your product better than anyone in the entire world. I can’t imagine giving that up no matter how much flexibility it gave me. I am happy to consult and do small projects to help other people refine their project/process/etc – but that’s not the same as doing it all the time.
What lesser-known/emerging tools/services do you recommend?
I feel like a curmudgeon saying this, but I don’t think tools are the answer. I think we end up with a lot of Product/Project management tools because those of us who make products use them – which means we think we can make a better one. I think most of them end up being better for the people who make them, but nothing works universally for every team.
I tend to focus more on getting things done and less on the tool (I will totally procrastinate by looking at tools). Instead of worrying about what I like, I worry about what everyone else on the team is comfortable with and willing to try.
Right now I use a combo of Google Docs + Google Sheets + Github issues – the reasoning there is that the first one is for the whole company (high level, easily digestible). The second is for the team that is managing things (good at looking at dependencies, keeping track of status). The third is for the people actually doing work (tickets, bugs, etc). So far this has been working.
For myself, I adore “DayOne” as a journaling product. I use it to get myself focused, write to-do lists, easily search for things, etc.
Communication-wise, I default to what the other person wants. I’m best at email, second-best at public tweets, pretty terrible at Twitter DMs, Facebook messages, Slack DMS, etc. I lose them and then feel guilty. I need an active “inbox” to find things, which is what email and Twitter mentions get me.
Hey Ellen, as you’ve moved from an “individual contributor” PM at Kickstarter to a “C-level” as VP of Product at Lola, what were some of the major skillsets you needed to adopt (or unlearn) in order to more effectively transition into more senior roles?
- OMG PMs are technical. I didn’t realize how biased my skillset was towards technical things until I started joining exec team meetings. The conversation takes a very different format. Details and “how we do it” becomes less important than making sure the strategy is right.
- I never got advice on how to operate on an exec team before I was on one. It was too late for me, but this piece from the CPO at TaskRabbit is great and I recommend it.
- Managing is hard! Especially managing non-PMs. I found I’d had enough background in influencing to do ok with managing PMs, but when I was managing designers it was very challenging for me. It can be hard to decide how much to push people to grow and what is reasonable to ask for.
Since you value teaching/learning, how can teams create a culture where they can learn from each other and grow skills? People may ask questions when they face a problem, but there’s a lot of knowledge that could be shared outside of that context as well. How can product owners help each other along the way and level up the whole team?
This is a great question! I unfortunately don’t have a great answer, but here’s a stab at it…
I try to get people to share as widely as possible. When I learn something new, I try to write it up and share with the team and set the example. I also try to realize when others are learning something and ask them to share with me and/or others.
This is also why I do a lot of 1-1 time. I think you can learn a lot just by talking to each other. There’s nothing wrong with having informal PM lunches together. You can also create more of a peer mentor group and set specific learning goals.
I recently started as Principal Program Manager at a leading consumer startup. But my heart is in Product. What are some ideas for making this transition? How and when should I approach the idea of moving into Product with my management?
- If you do have a Product discipline, figure out what you do differently from the Product Managers. Try to figure out how to build that skill set, and then look for an existing opportunity or gap in the product team. Make yourself the obvious choice when it becomes clear they need to hire for that role. My friend Ian at Kickstarter came to talk to me (Product) when I first started, and he was in Service. I spent a lot of time talking to him about Product and when the internal tools PM we’d had left, he was the obvious choice.
- If you don’t have a Product discipline, figure out why and who is getting the job done now. Is it getting done? If not, it might make sense to make the case to management for why it needs to and what is falling between the cracks.
Are there any thoughts/advice commonly recommended to product people that you feel are misguided or have a different opinion about?
Hmmm. I think PMs often feel that they need to have the idea and/or make the decision. I view my role more as “guide by the side” or “facilitator” or “nudger” – I make sure we go in the right direction, but I don’t need to be yelling with a megaphone all the time.
Based on your experience, what has been your ideal workflow for design -> dev hand-off and QA?
I think the best thing is small, autonomous teams. Ideally a product, design, development work together to ship a thing they are proud of. Everyone should have agreed on the goals at the beginning and then use their best judgement. I’m not a fan of strict job titles or responsibilities – I prefer everyone to use their best talents. This works best in small teams and smaller companies.
On Sundays you do “Deep product thinking” – what is deep about it/how do you do it?
It’s usually a specific goal. Like the original spreadsheet (in my doc/spreadsheet/github issues) came from one Sunday. A set of design tenants came from another Sunday. A set of what the key metrics should be was another one. I think over time different pieces of the product process are weaker/stronger, and I use that time to shore up whatever needs it. It’s more of getting 2-8 uninterrupted hours to think about how I want to work on one specific thing to help make the team/product stronger.
Who are some product people you really admire (that most might not have heard of yet) and why?
I love so many people who work in Product, so this is going to be impossible. In Seattle: Ian Todd (Microsoft, GPM Zune), Bill Stauber (Microsoft), Adam Feldstein (Moz), Lili Cheng (Microsoft). In New York: Jenn Vargas (although nomadic), Steven Benario (Pivotal), Jessica Harllee (Design, not PM, Etsy), Melody Koh (Blue Apron), Leland Rechis (worked with me at Kickstarter), Bo Ren (Tumblr), Kaya Thomas (Dartmouth and more as an engineer but builds cool things!) in Boston: Kristy Tillman (design, going to Slack and leaving us for SF), Sam Clemens (InsightSquared), Adam Sigel (logmein), Fraser MacDonald (logmein) in SF: Sara Mauskopf (Winnie), Kathy Chang (Twitter), Diana Kimball (Quip). Terri Burns (Twitter), Bianca St Louis (former Pinterest). Seriously I could go on for years and I’m sure I’ve already offended all the people I didn’t name.
What are your thoughts on addressing economic, racial, and gender inequality in the tech industry?
I think this is the single most important thing we can do to make our industry stronger. If you think about it, right now a very small percentage of the population feels that product jobs are accessible. I LOVE this job. I think it is the most fun thing in the entire world, and I feel incredibly depressed every time I realize a large chunk of people are told it “isn’t for them.” Everything I do like this (writing, sharing how to do product better) is really at the heart of trying to make it accessible so more people can do it. The impact I have by getting more people into this matters more than the product work that I can do as an individual.
The first thing we can do is to start to realize we’re all impacted by bias. If someone calls you on something, they aren’t saying “you’re a sexist” or “you’re a racist” – it’s that you did something, and luckily that’s often fixable – especially going forwards. I actually got a leadership development profile back yesterday, and I looked at the raw traits and went “huh. I guess I act super masculine.” Then I turned the page and saw the analysis from the firm, which was.. “you act like a leader.” If I think that about something about myself, it could definitely come out in how I treat other women.
I think the next most important thing we can do is to hold ourselves honest to this. Tracy Chou’s spreadsheet was a great starting point for engineering data. It’s great bigger companies share that now. Be honest about what you do. I’m a little bummed that both of the people on my team are not from underrepresented groups in tech, and it’s something I think about when hiring (and make sure I see diverse candidates). Keep track and hold yourself accountable.
Last, PLEASE PLEASE PLEASE speak up when you are safe. A lot of why I’m free to speak on these issues is because people have supported me. If your company has an unequal parental leave policy – say something. Men not getting as much time directly leads to women leaving the workforce. If someone keeps calling everyone “guys” all the time, say something. Add the slackbot. If you are in a position of privilege and you stand by waiting for someone else to fix this, you are part of the problem.
It is okay for this to be uncomfortable. It is not okay for it to keep going forever. I fully expect to keep working on this for the rest of my life, and it’s going to get better when everyone does a little bit – not by a couple people doing a lot (although I am also grateful to those people).
I realize a lot of that is on gender because that’s what I have the most direct experience with, but I also try to elevate the voices of those who have more experience with race and income inequality.
What are your opinions on having someone do Engineering and Product together on a large-scale project. What are some of the things that he/she should be wary about?
This is definitely a warning zone… ESPECIALLY on large scale. You need to draw a hard line with “here’s the right solution for our user” and then “here’s the best technical solution” and “here’s the easiest/fastest solution” and then make the tradeoff. It’s important to think about the implications of those tradeoffs and actually write them out instead of just making a call.
How does a PM know if he is doing things the wrong way (with respect to roadmap, execution, and product iterations)? Is there any process one can follow/put in place to provide an early warning system when this happens and do course correction?
I think the best thing here is to figure out…
- Are we shipping stuff?
- How is that stuff performing?
- How does the team feel?
If all three of those are good, you’re doing fine. If those aren’t working, then figure out which one is going wrong and try to collect feedback there.
I’m so interested in the travel space and I think Lola is a really cool iteration of a modern travel agent in a way that makes sense for people now. Did you work in travel before Lola? What have you learned about doing product in that industry?
I didn’t! I’d always cared about travel – I travel a ton personally, and part of my “Grand Challenge Scholars” Engineering portfolio was a section on travel/globalism. For some reason, I’d never realized I could actually work on it.
I love working on travel now. I’ve definitely learned it can be tricky to work on something like this. At Kickstarter, I could back a project every single day if I wanted – there never needed to be a gap for testing things. Now to test my end-to-end experience first hand, I need to actually plan a trip, which is a higher bar (time and financially!)
It’s also made me reflect on how much “tech” isn’t really an industry. Tech is just something that gets layered onto other industries. We build tech, but it’s really still about that core travel experience.
What are some mistakes you made or misconceptions you had when you first started out as a PM now that you’re a bit further on in your career?
- It was all about me. People are not reading into what you do NEARLY as much as you think they are.
- You are “ready” to have the scope. I was super impatient to run a team, set the entire direction, etc. I didn’t know nearly as much as I thought I did.
- Getting the right product is the “hard” part – every discipline has just as much nuance as product or engineering. A great sales strategy is just as hard to develop.
I think this is basically saying that a lot of early product managers tend to be rather arrogant (or at the very least me – and many junior people I have talked to) and you realize over time how much there still is to learn.
I’m going from an APM to PM role, and strategy is a new area for me, which I would like to work on. Do you have any tips or things that you’ve learned that would help me in this transition?
Strategy is a tricky one. I think it’s built via practice. I recommended earlier that someone read Stratechery, which I love as a way to start to wrap your brain around business strategy. I also think making guesses about what big tech companies will do at major announcement events (and why) can help. Discussing new products and how/why they work is also good – like hanging out in ProductHunt to ask founders questions about new things, for instance.
What communication strategies did you deploy (or recommend) to ensure stakeholders knew the near and far-term roadmap?
I mentioned before that I have a doc. I send a monthly roadmap doc to the entire team. I also have the spreadsheet, which is used by people who are closer to the product to plan 3-6 months out. At a smaller company, past that you are more guessing and it rarely stays the same.
As a product manager, I am sure you often see how designers and developers have an incredible potential to be great product managers themselves, however, it is hard at a company to promote everyone with potential because there are less “product” roles than designers and developers. How do you make sure that designers and developers are maximizing their potential?
I think the key here is that product is not a “promotion” – it’s a lateral move and separate discipline. I don’t think you are reaching more full potential by being in product vs design or development – it’s just a different type of work.
In terms of making sure designers/developers reach their potential, I think that’s up to their managers and their personal goals.
I try to make sure I set people up for success. If I know a designer wants to present things, I try to let them instead of doing it myself. If an engineer wants to be involved in upfront planning, I try to let them do so.
Referring to your post on Learning in Product I currently have a fairly good idea of what I want and need to learn but am faced with a manager and company culture that values certifications a lot. I rather learn on the job or pick a specific project to further my skills. Any suggestions on how to convince my manager or a certification you can recommend?
This one is hard because it’s really about your specific situation and I don’t have much context.
What cert would work really depends on what you need to demonstrate and what certifications your manager recommends. There’s no catch-all – that’s very targeted to the person.
In terms of convincing them, again, it’s more about the type of argument they find convincing.