After spinning up a product team for Coffee & Contracts and launching a new SaaS offering, we noticed a churn problem: too many new members were cancelling within their first month.

At first glance, churn can look like dissatisfaction with the product. But when we dug into the data and member feedback, a different picture emerged. People weren’t unhappy — they were overwhelmed. New members simply didn’t know where to start, and many never got off the ground.

We reframed the challenge: this wasn’t just about retention, it was about activation. If new members could get an early win, they were far more likely to stick.

We redesigned the onboarding flow with that in mind:

Quick tours that highlight the most valuable features

A simple intro resource to set expectations

A progress checklist that builds momentum

Invitations to join the community or attend an event

Each step was designed to create confidence, clarity, and connection with the product right from the start.

Members who skipped onboarding were the most likely to cancel

Members who engaged with just one step had half the churn rate

Events were the game-changer: members who attended an event almost never cancelled

Hands-on activities (like tours) outperformed passive ones (like watching a video)

The real problem wasn’t churn - it was lack of activation.

The first week is everything. Early actions determine whether members stay or leave.

Value-driven activities drive retention. Community and events are especially sticky.

By shifting the focus from reducing churn to helping new members win early, we created a practical path forward: guide people to their first success fast, and retention takes care of itself.

✨ If you're seeing churn in your SaaS product, we can provide a product team to iterate on it and solve it together — let's chat.

By shifting the focus from “reducing churn” to helping new members win early, we guide people to their first success fast, and retention takes care of itself.

The First Week Matters: Reducing Churn in SaaS for New Members

At Input Logic, we help digital products grow by designing experiences that convert curious visitors into loyal customers. One of our client’s products, a subscription platform for real estate agents, wanted a better way to introduce potential members to their product.

Here’s how we helped them launch a free trial that now brings in new sign-ups every week.

 from potential members to paying subscribers.

Previously, we offered a mailed free week of materials. While it gave potential members a taste of the brand, it wasn’t fully integrated into the platform. That meant missed opportunities to:

Convert more potential members exploring the site.

Transition from a mailed sample into a seamless, digital-first product experience.

 access, without waiting for something to arrive in the mail.

, showcasing the real value of the platform.

, building confidence from the first click.

The free trial wasn’t just a marketing tactic - it became a fully designed onboarding flow into the product.

The shift to a digital trial had immediate impact:

The free trial now brings in hundreds of new sign-ups every month.

, supporting sales outreach and long-term growth.

Free trials aren’t just about giving something away - they’re about creating an experience that helps users see value right away. By rethinking how potential members explore the platform, we turned curiosity into conversion.

At Input Logic, we design trial and onboarding experiences that move users from “interested” to “invested.” If your product needs a smarter path to conversion, let’s build it together.

How through offering users a free trial of the app in a demo environment we acquired new users and converting trial users to paying subscribers by allowing them to experience the value of the app.

How We Turned Free Trials into New Members

At Input Logic one of our clients, a subscription platform for real estate agents, came to us with a clear challenge: too many cancellations.

Here’s how we helped them reduce monthly cancellations by over 30% — while giving their members a more supportive experience.

For many individual real estate agents, business runs in seasons. During slow periods, agents often look to cut back on expenses - and one of the easiest cuts was canceling their subscription.

The issue? Their previous cancellation flow was very light and frictionless. Members could cancel in seconds, with no reminder of what they were leaving behind. This meant:

Loyal members were churning unnecessarily.

Returning members often lost their grandfathered subscription pricing.

We redesigned the cancellation flow to strike the right balance between friction and flexibility.

 extra steps that encouraged members to reflect before canceling.

 highlighting what benefits they’d lose if they left.

 giving members the ability to temporarily pause instead of canceling outright, while keeping their subscription price when they returned.

 after their pause period (and some before that).

, which built trust and encouraged long-term retention.

Reducing churn isn’t about making it hard to leave. It’s about making sure people understand the value of staying - and giving them flexible options when times are tough.

At Input Logic, we help subscription products design retention flows that reduce churn and grow revenue. If cancellations are hurting your business, let’s build a smarter solution together.

Learn How We Reduced Cancellations by 30% and reduced member churn through encouraging members to reflect before canceling with personalized messaging highlighting what benefits they’d lose if they left. And a Pause option giving members the ability to temporarily pause instead of canceling outright, while keeping their subscription price when they returned.

How We Reduced Cancellations by 30%

, a community where top talent come together to accelerate their ideas and careers. Rishi digs into his experience at Google, his lessons from spending an intensive summer working with 

, and how he's applying product thinking to the Chief of Staff function at On Deck.

Hey Rishi! Thanks for joining us. So you recently started a new role — congrats. Can you tell us about that?

Yeah! So I transitioned away from my product role [Product Manager at On Deck], which was more of a generalist role, into now being the Chief of Staff.

The way I think of it is, I’m still a Product Manager, but instead of a technology product, my product is the company — the team, the executive team, the board. That’s the framing I’ve given myself.

So the question is: what should the company be working on? What’s the right thing to build? How do we make sure everybody’s bought in? I'm using a lot of the similar skills that I’ve learned, having done product prior to this, but applied in a different and slightly more abstract context.

That’s cool. How’d you come to be involved with On Deck? What was your progression like to get to this point?
Whenever I talk about this part of my journey, I always start at the beginning of college. I was interested in biotech and basically, I wanted to cure cancer. I very quickly realized that wasn’t gonna happen. I started off doing biomedical engineering, and I did an internship at a medical robotics company. And I realized, healthcare is really slow. I was working on something that wasn’t going to be launched for years and years. I wanted to do something faster, so I transitioned into electrical and computer engineering.

I did a product engineering internship, which I though was interesting, but at the same time I didn’t feel like I had enough context on why I was building what I was building. That was the piece I was missing. I liked the technology, but I didn’t really know how it was being used, or why I was being paid to build it. So at that point I started to think that, based on my experience, I'm someone who needs to understand the context of what I’m building, and I want to move fast.

That drove me toward product development work. I'd heard about 

 — apparently a lot of people say good things about it. I applied, and there were some folks at Duke who had done it in the past and were generous to enough to help me out with preparing.

Nice. What was your time at Google like? And your journey from there?

I did the software development internship in summer 2019. I had an amazing experience. Really, it was great. There was a great community, I was learning a lot, sort of like a structured mentorship. I really got to understand how a big company works.

Ultimately, there were parts that didn’t 100% jibe with my own work style. Sometimes the company just felt so big, there were so many different groups with their own distinct goals. That creates almost a sense of competition, and I wondered, why do I feel like I’m working head on with people I should be collaborating with?

So I thought, if I were to come back, I’d like to be part of a smaller team that’s not working too broadly across all of Google. Working broadly like that is a skillset, of course. But I really wanted to learn how to build cool web and app products. So I accepted a return offer to Google, and they had me fill out a form to express my preferences for where I wanted to work. I told them that I really wanted to be part of a small team, just a few product engineers and a designer, maybe. And I wanted to be working toward solving a very specific problem for a very specific user group. Technology from the ground up. It didn’t need to be glamorous, I just wanted to figure out, “how do you build the right thing?”

Which, it turns out, is the core of product management.

I got the perfect team — they assigned me a small education team. And education is an interest of mine, which was great.

I was ready, I had signed the offer last fall. And then through the summer, I did some work in the startup scene with Steve Schlafman, an angel investor and venture capitalist based out of New York.

I worked with him doing sort of an apprenticeship. I thought I knew how the startup ecosystem worked beforehand, but I really didn’t understand it until I did that apprenticeship. I got to see how stuff really gets done. It was a really, really formative and incredible experience for me.

I publicly shared some of the work I was doing to support founders, and I ended up hearing from the On Deck team. They were like, “hey, we’re building something in the startup space, we’re helping founders, furthering education, bringing people together, creating community” — all of that was really interesting to me!

I was so blown away by the caliber of the team, the mission, the vision, the possibilities for growth — so I ended up signing the offer to join On Deck instead.

You mentioned that working with Steve taught you a number of things about the startup ecosystem that really surprised you. What were some of the lessons you learned?

I’m so grateful for that experience. He basically had me riding shotgun all summer, sitting in pitch meetings with founders, reviewing deals, doing diligence, learning how the entire capital network and founder ecosystem play together.

I was learning a lot about how companies start, and grow. And it was so inspiring. I realized that, although I was really excited for my development job at Google, I was nowhere near as excited as the founders we met with were about the things they were building.

I’d say I’m pretty entrepreneurial, and that experience really reinvigorated me. I thought, wow, that seems really cool, to be on a journey where you’re that excited about your work.

And that’s a big problem I see — so many people are unhappy with their work. Maybe I’m pontificating a little, but if we’re going to spend a third or more of our life on something, we might as well enjoy it.

At the same time, that summer I also learned that the hardest thing is meeting with founders who are really trying to further a mission, and having to say “sorry, we just don’t see it the same way.”

[You can read more about Rishi’s summer with Schlaf

, and his last-minute decision to join On Deck instead of Google

You mentioned education — what is it about that space that interests you?

I’ve always been a really curious person, and I’m really grateful that I was raised in a family that encouraged that in me. I was never told that I was asking too many questions.

At the same time, school and college were often frustrating because I felt like I wasn’t learning what I wanted to. Plus, schools have no incentive to help their students succeed, beyond ensuring that they can get alumni donations. I just think education can be a lot better.

And I think that if we can show people what’s possible in the world, they can make much better informed decisions about how they want to spend their time, and what they want to work on. So education is really important.

The combination of education and entrepreneurship in particular is really valuable, because they’re positive. It’s not zero sum. If you’re educating people, you’re not creating scarcity and selling that. Instead, you’re almost creating something out of nothing. Best of all, once you receive an education, whether you paid for it or not, nobody can ever it take it away from you.

Love that framing! How does the product culture at On Deck differ from what you’ve seen or heard about elsewhere?

One thing that stands out is the culture of experimentation. We experiment with everything, from the literal software product that we’re building to support our communities, to the programming, to even the actual fellowships that we launch.

One of the first initiatives I led when I joined was the launch of On Deck Labs, which is our business unit that essentially tests out new fellowship ideas for communities that we can build around the identities of ambitious people. We’re really encouraged to get feedback from the external world, from our customers and users, and people who want to see us succeed, as well as our detractors and people who are skeptical of what we’re building.

Everybody is very customer-focused and mission-driven, which really impacts the way we interface with our community. I’ve really grown to believe that every function is a product function — you have a goal, you’re trying to design a process that works. Sure, you can say “well, everything is also engineering and everything is also design.” But I think there’s something to the idea that we want to choose a set of outcomes, and we’re going to do what it takes to get there.

So how do you view your new role through that lens? What are things you can do when running a staff function that people normally don’t think of?

The Chief of Staff function is kind of unique, because the job is essentially to supercharge the company, the leadership team and the board to make sure we’re working on the right things.

And what you’re building is a company and a culture, and a leadership team that is empowered to do their best work. I think there are a lot of interesting opportunities in a remote environment in particular, working with a distributed team, where we have access to so many different tools.

You're also thinking about how to manage constraints. Constraints around a product team might be timeline or engineering resources, for example. Whereas constraints I’m looking at are, “where is people’s attention divided? What do people care about internally? How can I collect qualitative data and look at metrics, and figure out ways for us to work at an extremely high bandwidth, but independently?”

And just like in a product function, your goal is to align people. In a distributed, remote team, what’s important is making sure that everybody has the shared context, that they’re able to do their best work and make good decisions. We don’t need everything coming top-down from the CEO. So how do we use Slack and Notion and Docs and the Drive to create shared context on goals and priorities? That’s the framework I’m attempting to build out.

It’s all about sharing context, as opposed to control.

Long story short, as a PM my job might be to unblock engineers and designers and marketers and big decision-makers, so it’s not that different. I still identify as a PM in this role.

On Deck started off in-person, correct, and has now transitioned to remote?

Yeah, it was a dinner series for three years, and then an in-person cohort for ODF1 and ODF2, and now we’ve transitioned to completely remote. That has enabled a lot of interesting things for us.

Number one is the power of technology — we’re now accessible to people around the world. Before, people were coming from SF, New York, etc. But now we have fellows from all over the world. It brings an incredible amount of diversity and perspective to the community, which just makes everything better.

We’ve also started to build tools to support the community at a global scale. On top of that, the team has essentially tripled in size since I’ve been here, and that’s way harder to achieve in person. In a way, remote has been a sort of forcing function that requires us to get our shit together and make sure we’re all growing in the same direction.

Do you have any practices that you think are unique to your team that are really useful when working remotely?

Yes. I’d say our internal community Slacks are the best Slack workspaces I’ve ever been in. There are a lot of best practices and tips and tricks we’ve learned over time. I think the average team, from what I’ve observed, uses something like 20-25% of the features of Slack or Zoom on a day-to-day basis. Whereas we’re always pushing the envelope. When we get the release notes from Zoom or Notion, we’re always like “wow, these features now exist! How can we use them?” So our team is always looking for ways to push the envelope.

Another thing we do is try to prototype everything in no-code first. So some combination of Slack, Airtable, Webflow, whatever — that way we can spin up prototypes really quickly, and see if a concept resonates with our fellows. And once we start to outgrow those tools, we’ll build it into software. That allows us to have a happy product team, and happy engineers, because we’ve already validated everything and we know it has product market fit. We’re clear on what the pain points are, we’ve got feedback — that approach really helps us out.

That’s awesome. Have you read anything recently that you’ve found super helpful?

, by Julie Zhuo. I have a couple of interns I’m now working with, who are amazing. Basically I graduated from college and now I’m managing people, so I'm on a steep learning curve and that was really helpful for me.

Do you have any favorite apps or products right now?

 as a collaborative product, working with our CEO, and I’m finding it really useful. It helps us to understand what’s on our plate, where we should be focusing, how we make the most of our days, etc.

. And if you wanna get our Product Thinking interviews in your inbox, sign up for our monthly newsletter below.

An  interview  with  Rishi  Tripathy

Today we're speaking with Paul Ortchanian, who runs 

, a Montreal-based product consultancy that helps businesses of all sizes develop and implement strong product management practices.

Thanks for joining us, Paul! First, can you tell us a little bit about your journey? How’d you get started, and how’d you end up where you are today running Bain Public?

Sure! I started off as an engineer. I did about 10 years of engineering, mainly on the front-end side of things. I was very close to UX, too, and eventually ended up managing scope on bigger projects. And when you’re working on big products, you really start to realize how important the management of scope and expectation are to creating clarity.

Because I loved UX as well as working on the business side of things, I made a leap of faith and became a Product Manager in San Francisco. I joined a startup and learned things the way many product managers do — the hard way.

Eventually I came to Montreal and realized we had a nice little startup ecosystem, but most of the companies here didn’t have a culture that was product-led. It was the same old story of, “do what the boss says.” These business weren’t really solving customer problems, but instead trying to build as many features as they could without really asking themselves the question: is this adding value?

So I decided to start a company that focuses mainly on evangelizing product management to the Montreal community. I try to bring some of my key learnings from San Francisco to Montreal, and implement product-led thinking.

We have a mix of companies here, both early startups and later-stage ones. Regardless of stage, many are in denial for awhile, and eventually realize that product is important. But they’re not sure how to go about improving things. And that’s become our niche.

That’s great. Thinking about organizational transformation, let’s say you have a bigger company that doesn’t have a very effective product culture. What are some things you’ve seen that are signs a company needs help, or needs to be thinking about product in a different way?

First up, defining what a product manager does is quite important. So if I were to ask the company’s product managers, what do you do every day? How do you define your role in your company? Ideally, the answer is “we’re taking ownership of a portion of the company’s growth, through the features that we’re launching, and we’re able to help the business achieve its next financial milestone.”

There needs to be some acknowledgement that sales or marketing are not the primary drivers of business growth. And that the product itself is going to contribute positively, by increasing revenue through upselling, preventing customers from leaving, finding ways to charge more for certain things, adding ways to acquire new customers, and so on.

We’ll ask the product team, “what’s the strategy? Are you making large bets on unproven markets? Are you competitively launching new features? Are you extending a product functionality to an established market? Or are you simply shipping with little discussion about impact?” If it’s the latter — simply shipping, with little discussion about impact — that’s a project manager, not a product manager. Because they’re being told what to do.

So then I go to the product leadership team, usually the C-suite, and take a reverse lens. I’ll ask them, “what do you expect out of a product manager?”

And you can tell based on their answers if it’s an organization that celebrates shipping features more than it celebrates solving customer problems, or business problems. That’s the starting point.

I like that framing. So let’s say someone is in a culture like that, and they want to implement better product-led thinking. But they’re not in the C-suite. What are some things they can do?

Usually I try to define the strategy with the product leadership team before defining product management. It’s a question for the founders, the top-level decision makers. Usually that includes sales and marketing, operations, the CTO, and so on. And the question really is, “is this plane being built as it’s flying off the cliff, or is there a plan? How do you empower your product management team through processes and tools?”

It just comes down to asking some pretty tough questions. The best question I’ve been able to ask is, “do you know which features in your product are contributing toward revenue? And directly or indirectly, which are the largest customers that are using those features?” Take a very metrics-driven approach.

And if they’re unable to answer that, and they say “well, the product sells itself,” or, “we have no clue, because we have an amazing sales team and they’re able to sell anything,” or “our marketing team works really hard to bring in new customers,” — then, they really don’t know.

I recently had a startup founder email me his monthly report, outlining an increase in the number of commits to his main code repository. He was celebrating that as a win. And he was really happy about a questionnaire they sent out that had a lot of responses. I wrote him back and said, “you know, those are very shallow KPIs.”

You can’t run a business focused on shallow KPIs. You need to know how much growth each feature is generating, and how each feature is contributing to achieving your next financial milestone. If you can’t answer that question, then you don’t have a product-led culture.

But once people see how that type of thinking can contribute to the business, it can start to infiltrate the company. On our end, we come in to help define that step-by-step process, as long as the leadership team is willing to make the change.

What are some challenges you’re facing right now in your role, running Bain Public?

First of all, doing what we do, coming in and saying to a company, “you’re gonna have to make all this change,” — that’s a pretty tough sell. You need a lot of credibility. People want to know your background, and they want to know you know about their industry. Oftentimes I hear, “what do you know about the [healthcare / fintech / etc.] space?” But it’s not about that. The reality is, our job is to come in, interview the team, get to know their product culture, and help them put in place a process to empower product managers and inject this type of thinking in their company. They’ll always be the experts at what they do. We’re just there to organize priorities, help work through the roadmap to make sure it’s contributing to the growth of the organization. So this is an ongoing challenge, creating the organic word of mouth and the pedigree to allow us to be credible.

The second challenge we face is the product management culture within organizations. Oftentimes you’ll get someone who wasn’t hired as a product manager — maybe they came in as a business analyst, a UX designer, a marketer, or something like that — and they’ve been effectively given the role of product manager.

In many cases, they’re extremely busy, they’re running the show without any work-life balance, and they’re just unwilling to stop and make changes.

I read a Reddit thread recently that talked about how the role of a PM is a lot less glorious than what you see portrayed. And that’s true. A lot of it is a grind. You’ve got to drop something to jump into a customer support call, and then you run to a sales meeting to make sure the sales team doesn’t sell stuff that doesn’t exist, and then you head over to marketing to explain the features you’re actually shipping, and help them with website copy to make sure it’s accurate. It’s a grind.

People get caught up in it and think, there’s no way to progress here. External people can’t come in and coach me. It’s denial, really. Because there’s so much growing and learning that needs to be done in this space.

They might be busy debating whether to use Kanban or Agile, but ignoring the fact that every day their boss, who suffers from Shiny Object Syndrome, comes in and whiplashes the team with a new feature. So which problem do they really want to solve: Kanban vs. Agile, or the fact that their boss doesn’t let them have a roadmap?

Willingness to be challenged needs to come from the leadership team and PMs alike.

By definition, you must be dealing almost exclusively with clients that are suffering from these challenges but at least looking to resolve them.

Yes, though I’d say there’s a large percentage of clients we work with that don’t even know what product management is.

That’s another problem. Maybe they’re brand new companies, they might even be pre-seed or at the ideation stage. Ideally, they’re looking to implement a product-led culture from the get-go, because the longer they delay, the more problems they’re going to have in terms of communication and culture down the road.

You just mentioned Shiny Object Syndrome. I think sometimes people are resistant to having a data-led approach to product decisions, because they think they know best, or their solution is new and they think the customer doesn’t know what they want. So they’re just going to be the visionary that drives this product.

How can a PM help facilitate a more rigorous approach to decision making?

, which is our framework. We bring in the entire product leadership team plus the PM. So that’s usually 4-5 people — CEO, CFO, CMO, etc., plus the PM. And we basically conduct interviews. We allow them to express what they think the priorities are from every angle.

Sometimes it’s not about making the right decision, it’s about making sure you have the right process, which is this collaborative discussion. This quest for learning together. So if you’re a PM, you’re in a position where you can get everyone together and help them learn. What are the constraints the sales team is facing? What about the marketing team? What’s customer support hearing?

And then the goal is to come face-to-face with the really hard problems, together. That way, there’s no one-sided bias from the sales team, or the marketing team, or the engineering team.

It’s all about asking the right questions, too. When they say they need something, follow up with a question: “how is this going to help the business? How is this going to allow us to achieve our financial targets? If this is a great idea, who’s the user that’s going to use it?”

This process of collective learning helps create trust in the PM, because people can see that the PM isn’t just dictating things. There are no egos in the room.

You might not bat for a thousand, but at least you’ll be able to hit, say, a 60% average in shipping the right features. And over the long run, that’s probably good enough.

Great advice. So how can you balance short, medium and long term goals when setting a roadmap?

It’s like wearing glasses — the closer things are, the sharper they get. The further out you look, the more blurry it gets. The crucial thing is always getting the next three months right, facing your immediate decisions.

Beyond that, your customers might change. Your competitors might change. Your market might change. You’ve got to be able to reevaluate every three months or so. That’s why we called our company Bain Public, because in French, bain public is a public bath. It’s a place where you go to clean up on a regular basis.

So the idea is, every three months a company cleans up their roadmap. Reevaluates what’s happening. It’s not about having full clarity on a 6 to 12 month roadmap. It’s mainly about having a high level mission.

You can have long term goals, but know that they’re blurry.

And in terms of setting top priorities, it’s best to come face to face with the worst problems. Often the company’s worst problems are the customer’s worst problems. Maybe something is broken and it’s creating a ton of support tickets. And you’re stuck with one resource who’s managing 600 tickets a day, which is humiliating. When you think about it that way — what’s humiliating? That gives you a good idea where to start.

What about a new startup that’s just launching for the first time? How can they think about prioritization?

Well I guess that’s your biggest problem, no one is using the product yet. First up you want to create your whole ecosystem. How does somebody buy your product? What happens post-purchase? Map out every step you want a customer to take from sale, to regular usage, and the output the product provides.

Then you ask yourself, “where are we faking it till we make it?”

When you look at your process, what you’ve built and what you’re faking, where are there gaps that could create problems for the customer? If something important isn’t yet automated, or data is being stored somewhere it could easily be lost, you probably want to start there.

What about PMs early in their career? What’s something you wish you’d known earlier?

I would’ve loved to be coached from the get-go. I used to be the guy who came into the room with the data, the numbers. Everything you read about product management, people are telling you to be an expert in the data, the market, your competitors, your industry. So you’ve spent time with the CTO and the engineering team. You’re an expert in the product and the database structure. You’re in sales and marketing meetings. And you think, “okay, I guess I’m an expert on everything and I’m here to tell everyone what the facts are.”

The thing is, product managers also need to be able to influence people. You need to be able to hear them out, hear their concerns, and frame the features you’re proposing within the context of their problems. And if you’re not listening, and you’re just the guy who’s coming in with the facts, you’re going to get challenged or pushed aside. And that was my biggest issue, originally. In my first PM role, I was fired. Not because I was a bad PM, but because I had a big mouth.

Once you lose credibility, you lose the room. It’s like being a hockey coach. It’s not because you’re bad, it’s because the players don’t want to play for you anymore.

The average lifespan of a PM within a company is often a year. It’s ridiculously short. I think a lot of it has to do with the fact that PMs have so much to assimilate in a short amount of time.

I talk a lot, and I had to learn the hard way to be a good listener. Maybe it’s not a good idea to go out there presenting a list of 10 Reasons Why We Shouldn’t Build This Feature, because the sales team is going to just go around you to the CEO and get their feature built.

That’s good advice, and very true. Last couple questions! What’s a product that you’re obsessed with right now?

One that I’ve always liked — I’ve been using it for about 10 years now, I think — is 

. It’s basically just a big to-do list. But the way the user experience has been thought out is great. Every feature adds value. I can’t get out of it, it’s just so much part of my day-to-day.

Any recent podcasts or books you’ve discovered that you’d recommend?

. It’s basically Product Management 101. I find the industry is becoming more mature, and I’m really happy that there are books like this that are the real deal.

For more from Paul on product management, dive into

. And make sure you never miss a Product Thinking interview — sign up for our newsletter below.

An  interview  with  Paul  Ortchanian

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 

 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 

. 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 

 — 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 

. We've built an entirely new experience to aggregate all code samples that Microsoft ships in the 

. And of course I can't neglect mentioning 

 — 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 

 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 

 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:

 Do we have any numbers that point us towards the importance of certain things?

 Do we have any verbal/written feedback that points us towards the importance of certain things?

 Are there any specific movements that we see in the space that we need to make sure we are part of?

Input Output

How We Created a New Mobile App Revenue Stream for Permission Slip

This week's links:

The First Week Matters: Reducing Churn in SaaS for New Members

An interview with Rishi Tripathy

5 Reasons Why iOS Developers Need to Switch to SwiftUI

How We Turned Free Trials into New Members

An interview with Paul Ortchanian

An interview with Gaurav Chandrashekar

How We Reduced Cancellations by 30%

An interview with Den Delimarsky

App Store Optimization tips for your product launch