Behavioral & Experiences Flashcards
Walk me through a product that you are proud of
Describe a past work experience
Talk about your experience working with customers.
I’ve worked with customers extensively during not only the discovery phase where I’m understanding problems and mapping the opportunity space, but also post-implementation when I’m gathering feedback to learn and refine a feature that my team and I shipped. I’ve been very privileged to work at companies - nTop and Microsoft that are very customer-focused and I’ve sort of blended some different themes to create my own unique approach or strategy to how I want to work with customer and my approach has three “pillars” or “threads” if you will and those are:
-ear always open
-active project - assumptions to validate
-open pipeline, scale the funnel
1. Ear always open - constant touch points. At nTop the VP of Product was very into Continuous Discovery habits by Teresa Torres, that was required reading, and he was emphatic about spending time w/ customers weekly & wanted us all to log our sessions officially in Catalyst. whether it be a formal interview or just being a fly on the wall during a session with a solutions engineer. And I think this is important for PMs, it's that constantly scanning, constant radar out to pick up on themes, to validate your strategy and pick up on any new themes that would inform a change in your strategy, and just generally hearing what's important to customers and top of mind. 2. Number two of my three threads is the active project - this is initiative that you have on the roadmap, and it's going to be in some phase of the product development cycle, and there are assumptions to validate, questions to answer, and the need to de-risk the project. So for example one of the features that I took from 0-1 at nTop is a new data conversion algorithm for users to export their preferred file type, and so not only was I intervewiing customers 1:1 but I also created a survey for CSMs to send out broadly to assess the value of the feature - would ppl use it, is it worth the investment. When I was releasing the next-gen latticing workflow I performed usability testing with the designer on my team - we were specifically answering if the new stuff was easy to use and how users felt about it. And often times you'll have more than one active project going. 3. And lastly is opening the funnel, there is only one of me, and I'm not going to be able to sit with all 12k datadog customers, so it's important for me to consider all the avenues that customer feedback can get to me to scale my intake - so at nTop I would meet with customer success managers who speak to 20+ customers, and we also got monthly reports from product support that I would read with info on what areas users are most frequently having trouble with. At Microsoft we had the Azure feedback forum and users could up vote different feature requests - and so you as a PM you want to tap into all these feeds and have a really broad and rich ingestion pipelines
What is the most recent project you did, and how you worked with engineer team on it?
Failed at something, challenge etc.
Tell me about how you work with engineering
How do you navigate an unexpected challenge with the product or feature?
3 What I did next was set up bi-weekly meetings where S and I would present to my manager, and my skip, as well as his manager, because I recognized that these folks wanted more frequent updates, we created a page with the latest info on the stage we were at, and it became their one stop shop for updates on the project.
-These things do come up, it’s not an exact science to estimating dev work because there are always going to be unknowns, which is why the agile framework came into being, because of the need to constantly align, plan, implement, retrospect, adjust.
-This is really fresh in my mind, because I just experienced this big time with the project I was working on at nTop.
We prioritized a major investment to create our own built in-house CAD kernel. The product was built on an open source solution that has some serious limitations - issues with scale, so dealing with a boolean union or subtract of 1000s of parts, and it wasn’t extensible, it wasn’t easy to add on to. They wanted to add some intelligent tracking so it was easier to know the history of an object and that will help when converting between data types.
-So the team had already done some initial research and prototyping, the devs had a design that was peer-reviewed, and so I set the next milestone for an internal beta for Q3 of 2023 - trying for September, and then the engineering lead goes on paternity leave, his name begins with an S so I’ll call him S. Which in and of itself doesn’t mean there’s going to be a crisis right, it just so happened to create a perfrect storm …
-Well, during the quarter the devs discover that wow the code is way messier then they thought, the current kernel is NOT behind one clean api. They knew that there was going to be some mess, that there were some direct calls that they had to track down, but they had no idea the extent of it. If I can give an anology they thought they had one messy broom closet to clean up, but it turns out to be a massive garage full of mess and boxes to sort.
So this really blew up the extent of the project, internal beta got pushed out by two quarters, and there was like 0 chance of the kerenel being released to users in 2023. Okay.
So what did I do ?
#1 immediately I surfaced this to leadership, yah know once the slippage is confirmed I don’t wanna sit on this info, I want to make people aware of it
Next I asked a lot of questions - okay we discovered something new, how big is it, what are our options, could there be any thing ELSE lurking in the shadows, let’s pivot and create a new, realistic plan. S returned at the end of the quarter and I was impressed bc he really took responsibitlity , hey I missed this, I should have been aware, and I asked if we could do a full hour, not just 30 min for our quarterly team retrospective.
Because what’s most important is that as a group we’re able to reflect and learn from these scenarios
Next what I did was offer to present at an all-hands, because there was a lot of FUD - fear, uncertainty, doubt that this project was taking so long and pushing out other initiatives, yah know sales, marketing, customer success they were all excited for the new kernel and it’s benefits but there was fear around how long this investment was taking, so I wanted to go drum up that excitement and buy-in.
So Suraj and I co-presented, I owned the “why is this good for our business and customers” portion and Suraj presented on some technical aspects and the speed improvments we believed we’d get.
And that really helped to re-generate re-up and get the excitement and we also shared hey this is our up-to-date timeline and what you can expect
So in summary I
-made folks aware
-asked a lot of questions, I asked for a longer retrospective and asked for an updated and realistic plan
-set up a page to host the project status & a leadership meeting
-did some cheerleading around the project and co-presented to the company
In conclusion, I want to mention that this types of major slippage in my experience are more rare. And what makes them rare? Well, having a good solid quarterly planning process where you’re looking at assumptions, addressing unknowns first, addressing big risks first, breaking things down into incremental milestones, and having a solid scrum process in place throughout the quarter, yah know that’s a lot of time investment going into those things, but its high ROI and pays dividends by avoiding this type of scenario.
How do you ensure engineers have freedom & autonomy and are solving the right problems?
I think this really comes down to creating the right interface and touchpoints between devs, design and PMs.
It’s definitely a balancing act. So I think of this as a spectrum so on one end of the spectrum you have total dev autonomy and freedom –> they might be down a rabbit hole solving for EVERY potential edge case, perfectly optimizing a piece of code, fixing all the tech debt and probably there will really be some innovation and creativity coming out of that. But that’ll come at the expense of the business moving fast and potentially not focusing on the right problems.
Then on the other side you have this robotic team, that’s just following orders, pushing out new feature after new feature at the cost of tech debt and low hanging fruit solutions that devs discovery or creativity to explore and innovate.
So how do you find a place in the middle, it’s not a perfect science.
So four things for me come to mind:
First it starts with a good collaborative planning where we go over and align on the problems we wanna solve and how that aligns with the top-down strategy such as increasing TAM or expanding into new industry verticals, and then chat with devs to get their ideas, bottom-up, so anyone can bring ideas. And I listen to them, and I have an open mind and I can allow myself to be convinced yah know.
Secondly I’ve seen success with a dedicated at least 10% of dev time specifically allocated to tech debt of their own choice/prioritization, but the whole R&D leadership team including PM leaders should give this the thumbs up, and I think this is important to specifically guard and allocate time.
Thirdly I think it’s important for PMs to be involved in SCRUM like sprint planning, standup, sprint review and retro, bc sometimes things will come up like hey Lyrana we found this edge case, when creating a mesh and I’ll ask okay how probable is it what’s the likelihood of it happening, what’s the severity of the issue, should this be a warning or an error etc. and I’m able to unblock them quickly.
Then the fourth thing that I can think of for creating that right balance is to formalize time in the form of company hackathons for example, with devs getting complete freedom to go explore something they’re interested in, we did this at Microsoft and I know it’s a big tradition at Facebook.
Yah so in summary:
-collaborative planning that includes bottom-up input and some time allocated to dev to select their top priorities, being part of the scrum team to keep that alignment going during the quarter, and then time for innovation such as hackathons or personal projects, and that shouldn’t be in addition to your sprint goals, it should be a first-class citizen, really have schedules free and clear.
How do you navigate situations where there may be friction or misalignment in goals between PM and engineering?
Tell me about a friction, misalignment, or challenge that you’ve experienced in the past.
How do you approach friction, misalignment etc.
How do you resolve conflict on a team?
How do you deal with strong personalities?
Let me give you an overview of my approach to resolving conflict and then I’ll give a specific example:
-It starts with relationship building, and this starts on day one, prior to when the conflict happens so that you have something in the bank. I want to be a good colleague, I want to do good work and be known as reliable and make connections with people and show them I care about them. So I establish a relationship with everyone such that if/when a conflict happens we have positive energy already in the bank.
-Second I try to think about how that persons’ people’s motivations and fears and where their own incentive structure might be pushing them one way or another, are they anxious about their performance or quota etc.
-Then I want to talk to them, not a back and forth on slack, but a video-on zoom meeting or in-person even if we can.
-Then see if there is a compromise that can be made, and then if there’s not, rely on who owns the decision - if it’s a conflict on the roadmap with a designer, which I’ve had before, then okay I’ve listened to your points and I have my own view based on data and I don’t agree and I own it. If it’s about the user experience and they own it, and I present my view and they have other data and experience, then they own it, and I can disagree and commit.
Here’s an example of how I put that into action:
During my time at nTop I was asked to step in as the interim PM for a sister team, the modeling experience team. Their PM had been let go of, their eng manager went to pursue another opportunity, and they had a dev on medical leave, so the team was in shambles, and my eng lead and I were asked to step up and act as interim, like keep the lights on, try to keep the motivation high.
And there were a lot of strong personalities in that group, immediately I recognized that I would have to change how I work.
The group was very meeting adverse and adverse to quarterly planning.
When I reviewed their Q1 plan in Jan I knew it was way too much. Some quotes that were said were yeah here at nTop the PMs just put anything on paper and none of it is reality.
And I said hey hold on a min that’s not my experience, Suraj and I have been through this for 7 quarters now and we’ve gotten better and better and the plan does mean something on my team so that’s not true it IS possible to be valuable
So I listened and got to the root of their fears which were that
-I was going to make a bunch of meetings that would waste of time, and then I would lie to leadership and say yes to everything and overcommit them.
This was challenging bc I didn’t have much rapport with these people yet, not much stored in the bank.
So I took action; every meeting I set up had an agenda and a list of outcomes, I kept it as short as possible. I had to make sure that when I communicated that I was very clear and intentional. I reviewed the priorities they had 4 epics and I picked one, so I worked with them all to trim down to like 25% of what was initially on paper, and I pushed back on a x-team ask from sim team said hey we just can’t do this right now.
I presented this new plan to leadership and everyone signed off on it and understood. And I think it was perhaps the first time some of them had seen their PM say NO to a x-team dependency request.
And by the end of the first two weeks they felt like okay this lady is in our court, she has my back. In March I helped their new PM ramp up and onboarded him, so it was a successful interim period.
It’s taken me a while to become at ease with strong personalities yah know because my default is peacekeeper, let me appease you, let me keep everyone happy, and I think that can be very effective and work well in most cases, but actually it’s something that my dad has helped me a lot with since we talk a lot and he coaches me is that hey I can be strong too. Technology is hard but compared to deal with people sometimes it’s the easier thing right.
