An interview with Den Delimarsky 

Welcome to our new series, Product Thinking! We'll be featuring regular interviews with super-sharp product managers, leaders and thinkers from a huge range of companies. Know someone who you think we should interview? Drop us a line!

We're stoked to be kicking the series off with an interview with Den Delimarsky, Principle Cloud Advocate at Microsoft.

Hey Den! Tell us more about your background. What have you worked on in the past, and how'd you end up in your current role? What drew you to product work?

I grew up always wanting to work in the IT industry in some shape or form, but when I thought about it, it was largely around the software engineering discipline. That is — I had no idea in my high school days that a product management track was even an option. Once I got into the computer science program during my college days, I discovered that there was such a thing as PM. I wrote about it in my blog — it was entirely an accident. However, once I discovered that product management is a thing, it was easily the best decision in my life to pursue this career path. The first steps of me being a product manager happened in early 2013, when I was part of a team at Microsoft that was called Home Activities & Experiences (HAX). As a PM intern, I was responsible for helping bring to market an innovative calendar planning solution. I loved the kind of work I could put into the discovery phases, customer interviews, and then be able to see the ideas take shape in close collaboration with my engineering peers. In broad terms, product management combined two of my favorite things — talking to people and the magic of software. Since then, I've worked on the team that shipped Outlook Desktop and Office 365 Groups, after which I jumped on the opportunity to build docs.microsoft.com from scratch, being one of the first PMs on the project. My latest gig was with Amazon, where I helped build parts of the EventBridge service. What I love about being a product manager, and what reaffirms that I made the decision on a daily basis is the sheer scope of work that I get to do — it's practically unlimited. I get to do everything, from talking to people who use the product I am building, to crunching numbers, and mocking up new experience designs.

What are the unique challenges you're facing in your role right now?

The challenges are not typical to my role, but likely are typical to the times we're in right now. COVID-19 has shown us that we'll need to adapt to a world with stressors that many of us have not seen before. Folks with kids, homeschooling, travel restrictions — these significantly impact our ability to focus and concentrate on building. The situation that we are in right now requires a degree of empathy from our leaders and peers — not everything will get done the way we planned early in the year. Availability of individuals may shift. Attitudes may shift. We all need to be cognizant of these factors. As one of my mentors says, "we're not working remotely. We are working remotely during a global pandemic." This is not your typical 'work from home' environment.

What is your unique ability that has allowed you to succeed in product roles?

kill stacking. Something that I've learned from my good friend and mentor Dan Fernandez. The idea behind this is fairly simple — generalization instead of super-specialization. I tend to combine a set of skills to get the job done. For example, I love writing code and working with data. This enabled me to leverage those skills in my career and help me be more efficient with my and my team's time. With code, I am able to quickly put together product prototypes or help unblock the engineering team when they have too much on their plate. I recall in 2017, when my team was tasked with building some documentation infrastructure, one of the tools that needed to be built was temporarily de-prioritized. I knew we had a tight deadline ahead, so I rolled my sleeves and wrote the tool myself. As far as I am aware, it's still in production today. Being able to wrangle data and discern meaningful insights from those that are irrelevant helped me quickly make decisions and settle arguments without having to be bottlenecked by the data science team, since their resources are scarce and likely already spread fairly thin. Notice how I don't say that I will do the work of the data science or engineering teams — they do extensive work, and are vastly more experienced in their domains than I am. I am pretty sure if they looked at some of my original code, they'd be horrified. However, it enables me to move fast and help my team deliver value to customers regularly. To all the folks that I mentor, I always recommend exploring some adjacent fields. Do you like user experience design? Are you a great orator? Do you have a knack for putting together great video reels? Put those skills to use. A product manager who only knows how to talk to customers and write a spec is silo-ed. A product manager who knows how to talk to customers, write a spec, put that into a Figma prototype, and pull the quantitative data to prove or disprove their product hypotheses is a force of nature.

What's one thing you've worked on that you're really proud of?

Hard to pinpoint just one thing, to be honest. I've been fortunate to work with really talented individuals in every team that I've been a part of, and we delivered great products. I'd say the most impactful product that I've been a part of was docs.microsoft.com — the technical documentation site for Microsoft. It's an absolutely massive project, with hundreds of stakeholders within the company, and millions of stakeholders outside it. I joined the team in 2015, in the very early planning stages of the site. It was exciting to build something modern, scalable, and with global reach, while considering the legacy of resources such as the Microsoft Developer Network (MSDN) and TechNet. We completely upended the traditional technical documentation model. No more proprietary systems — it's all on GitHub and written in Markdown. There are multiple modalities that allow you to discover every single API that Microsoft ships for a language, such as the Python API Browser or the .NET API Browser. We've built an entirely new experience to aggregate all code samples that Microsoft ships in the samples browser. And of course I can't neglect mentioning Microsoft Learn — the service that allows anyone around the globe to get skilled in a variety of technologies, entirely for free. Working as part of the team that delivered all this is what I am most proud of.

How do you foster collaboration within your team? Any tools or processes that are working really well this year?

I am taking a bit of an unorthodox approach here. As someone who worked remotely for the past 4 years, I can confidently say that tools themselves are just that — tools. They don't matter as much as the underlying collaboration culture. You can have fantastic video chat software, but if the culture is not there to work asynchronously, it's not going to help you or your team. One of the things that I try reiterating to my team is that just because we are now not in the office doesn't mean that we need to shift every meeting that we ever had into an online environment. Quite the opposite — this is an opportunity to reevaluate what meetings are really necessary, and where we need to start working offline. It all starts with culture where the team understands the value of not being constantly interrupted by Slack notifications, emails, and Zoom calls. To that extent, to me collaboration means that I show how my team can focus and work when they allocate time for it. I really like the approach that Basecamp is taking here — they are THE company that knows how to do distributed work right. One of the points that stuck with me, that I see a lot of teams fail at, is the fact that communication is not tied to calendars. Way too often we wait for "time to sync" or "discuss during the planning meeting." That's a completely unnecessary roadblock. Why not write a one page document that outlines the pros and cons of an issue, and I will get back with feedback when I have time, if it's not urgent. Or write an email, and I will respond with some thoughts whenever I am not focused on writing the product vision outline. The best way to collaborate is to build enough flex in your process that accounts for everyone's work styles and time allocations. And of course, meetings does not mean collaboration. As a matter of fact, meetings are generally the opposite of that. The more meetings your team has, the more their focus is destroyed. For the love of everything, please stop making everything a meeting and give people space to think through a problem and come up with some thoughtful input.

How do you manage prioritization and roadmapping?

This will vary between teams, but I like to keep it very simple. The inputs that I look at are:

1. Quantitative data. Do we have any numbers that point us towards the importance of certain things?
2. Qualitative data. Do we have any verbal/written feedback that points us towards the importance of certain things?
3. Emerging/established trends. Are there any specific movements that we see in the space that we need to make sure we are part of?
4. Unknown unknowns. Are there any new opportunities that are not yet understood/seen by others that we can be a part of?

Once you have reliable data on the above (and getting truly reliable data is hard and is what needs a lot of focus from product managers and their organizations), roadmapping and prioritization becomes easy, because one can clearly see where they can deliver the most value to the customers and the market. Whether it's then put in a JIRA board, or Trello, or whether story points are assigned to each item doesn't matter. The team needs to first understand the "Why" and "What." Everything else comes from these insights.

When it comes to product, how do you know when to trust data, and when to trust your intuition? Have you ever taken a risk based on your intuition that paid off?

These are not mutually exclusive. You can't rely just on data or just on intuition. It's always a combination, like I called out in the previous question. Anyone that relies exclusively on one or the other is going to either be lucky or wrong. Hard numbers rarely tell you why customers do what they do. Qualitative data coming from user studies only shows you a sample of your total potential customer base. Your intuition can be wrong more often than not because humans are terrible at identifying their own biases. So to mitigate risks, a product manager needs to take the approach where they look at multiple inputs, and then determine a path forward. This is where I am a HUGE proponent of experimentation, which I think is an area that can yield massive benefits to any team. Experimentation enables you to test hypotheses at scale. I'll frame this as an example — say that you are building a site where there is a sign-up flow, and you've noticed that a lot of people are dropping off right before they reach the last screen. Looking at just numbers, you see the drop-off — it doesn't tell you why. A data-savvy product manager or a data scientist might take this a step further and try to look at cohorts — where are the users that are dropping off coming from (e.g. mobile devices, a specific geographic region). This is still an incomplete story. Let's say that the next step is that the sign-up flow is passed through a user study. The product manager teams up with a researcher and they talk to seven people, all of whom went through the sign-up flow. The product manager and the researcher notice a pattern — the users struggle to identify which fields are optional and which are mandatory, and at some point they give up and quit. That's now the basis for a hypothesis — because the data is limited to seven people, it's hard to say if everyone is experiencing the same problem, but the PM intuition tells that "this is likely the blocker." That is not concrete, undeniable evidence. So there are two options for the product manager now. They can go to the engineering team and talk about prioritizing field changes, to make it clearer which are optional and which are required, which would mean some form re-design. If they take this approach, they may solve the problem, or they may make it worse — who knows? Alternatively, the PM can set up an experiment, where they roll out changes to a limited audience to gauge the impact before making a decision.

What's your favorite app right now? Why?

Safari. I've been spending more time just reading things in the browser on my phone. Modern websites are really well optimized for mobile devices, and in a lot of cases have less negative privacy implications. Other than that, I am a big fan of Overcast by Marco Arment. It's a delightful podcast manager.

What's the last book or podcast interview that totally wowed you? 

Probably too many to name — I consider myself to be both an avid reader and a podcast listener, which means that my podcast feed is always overflowing and I have way too many books that I try to read at the same time. The latest book that I've read that really impressed me was Founders at Work by Jessica Livingston. It's an older title (12 years now), but it goes into detail about how certain companies and products were started, and it's fascinating to see how creative founders got with technology that nowadays we take for granted. Truly, constraints breed resourcefulness. From the podcast side of things, I will call out StartUp and its early episodes, where Alex Blumberg talks about creating Gimlet Media from scratch — it really shone a light on how a company is started from an idea to something that people love.