After countless hours of work and calendars filled with meetings, your app is ready to submit to the app stores. How will you get users to discover the product of your hard work, increase adoption, and download it? App Store Optimization (ASO) and paid marketing are the keys to a successful launch.

ASO can be broken down into two main sections: keyword optimization and creative optimization. Paid marketing efforts include running ads from platforms that can not only help your new user downloads, but also offer organic coefficients. Using both of these marketing strategies to their fullest potential will yield the highest results for your app launch and over time as your app matures.

Keyword optimization drives ASO visibility. You want users to be able to find your app organically by searching for a keyword, and seeing your app in the search results.

Keyword optimization is a crucial part of increasing organic discoverability. Selecting relevant and specific keywords with high search volume before launch will help set your app up for success. If your app is ranked for these keywords, then your visibility will increase because more users will see your app in the search results.

When you deploy a new build, the store algorithms will begin to merchandise your app for roughly 3-4 weeks. During this process, the algorithms will scan the metadata for targeted keywords and possibly merchandise your app for additional rankings. Starting with strong optimized metadata helps Apple and Google easily understand your app from day one. Take note of which keywords or phrases perform the best using ASO software, and test them in your next build.

Optimizing your metadata can help your app rank for hundreds or even thousands of keywords and phrases, effectively expanding your overall organic presence. As you gain impressions and installs from these rankings, your app will build relevance in the eyes of the stores. This can, in turn, increase rankings -- which further expands visibility.

Keyword discoverability will allow users looking to find an app like yours to discover it. But after a user sees your app, will they download it? Creative and conversion optimization drive the download part of your ASO strategy. All traffic eventually leads to your app store listing. Your on-page search and product page elements need to convince users to tap to get your app, and not a competitor’s.

A picture may be worth a thousand words, but effective app store creative can be worth thousands of installs.

Optimizing your creative assets will improve your conversion rate, maximizing the impact of your increased keyword visibility. Increasing your conversion rate can help your app climb up the ladder of keyword rankings, because app stores take conversion into account.

When working on creative, start by implementing best practices to improve relevance with your target audience and increase conversion. For example: highlight key features in the screenshot copy or in-app UI. Users are more inclined to install an app if they immediately recognize their search queries, whether it's through keywords or in-app imagery.

A/B testing tools are also important for optimizing your metadata and creative. Testing gives you quantifiable data to understand which aspects perform the best. You can test various aspects, like which colors convert the best, or which keywords to highlight. From there you can build upon the success of previous builds to continually improve performance.

New apps will get little organic traffic because they don't have high rankings for high volume keywords -- it takes time to build relevance for the algorithm. This makes it hard for users to find a new app, without a little help.

Paid marketing from healthy channels, like Apple Search Ads, Google Ads, or Facebook Ads, will increase the volume of traffic to your app store listing, and help stimulate the store’s algorithm to index your listing at a faster rate. This has three benefits:

Improve organic keyword ranking visibility

Increase your user base at a quicker pace

Paid traffic is different from organic, because you're directly bidding for placements that can appear either above, or entirely outside of, organic search results. These paid placements can be at the top of the search results for Apple Search Ads, or a banner on a YouTube video for Google Ads. As your listing gains installs, you become more relevant in the eyes of the store, potentially increasing overall organic rankings.

Each paid channel has unique pros, cons, and a different level of influence on organic. For example, Apple Search Ads can have a direct impact on how your app ranks for keywords, and will display the screenshots already used in the App Store. Facebook Ads, on the other hand, will help with the overall volume of installs with an indirect impact on rankings. Facebook Ads also require creative assets made specifically for Facebook.

Start with the channel that best aligns with your marketing goals, budget, and team resources to help scale your user base. As your app usage and business grow, you can look into adding more channels to capture additional demographics.

ASO keyword and creative optimization together form an iterative process of research, testing/deployment, measurement, and improvement repeating. This cycle of continual improvement, paired with paid marketing to boost traffic, will set your app us for success.

Even if you've developed the best app ever, no one will know about it if they can't find it. ASO helps your organic visibility, by targeting relevant keywords and improving conversion performance with creative assets. Paid marketing supports your organic visibility, by driving additional traffic volume. Avoid a slow start after launch by using a combination of ASO and paid marketing strategies to get your app in front of the right users.

 is a global leader in App Store Optimization with more than 11 years of experience optimizing and marketing apps. We offer the leading enterprise ASO technology and agency services, providing support to clients around the world. Our company is trusted by thousands of enterprise brands and leading startups including Microsoft, LinkedIn, Bethesda, SWEAT, GrubHub, McAfee and many others.

App Store Optimization tips for your product launch

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?

 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 

 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 

 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 

 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.

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 

 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 

 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 

 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.

An interview with Den Delimarsky

It’s been a year since the introduction of SwiftUI — and if you’re an iOS Developer, now is probably a good time to start considering it as a viable option for building your next app. On its initial release, it was a hard sell to anyone who needed to support older versions of iOS or who didn’t want to deal with the aches and pains of adopting a brand-new framework, even though it offered a graceful, elegant way to build out User Interfaces (UI). But, after giving it some time to mature, and the 

 13, SwiftUI deserves a serious look when making your next app.

Apple has taken a new approach with SwiftUI — offering a declarative solution to building out your User Interface. Traditionally, using UIKit and AutoLayout, we’re used to seeing an imperative approach at building UI.

If you’re unsure of the difference, think of declarative as telling something 

For example, if I were to hail a cab and tell the driver where I was going taking an imperative approach, I’d say something like, “Accelerate slowly and take the first left turn, drive for 5 minutes and take a right turn on 99 street. Drive for 2 minutes, and stop at building #3905.” With a declarative approach, I’d say, “Go to 3905 99 street”.

The imperative approach in iOS development often results in complex, hard-to-read files, filled with overloaded, and overridden methods — even for the simplest screens within your app. With SwiftUI, we’re able to build clean UI that’s easy for people to understand even if they aren’t familiar with Swift or iOS development.

For things like project handoffs and onboarding new developers, this is a huge win. You’re also getting the added benefit of not having to worry about breaking constraints, and ambiguous layouts like you do with AutoLayout. Your layout either works, or it doesn’t.

Because you’re using a declarative approach with SwiftUI, you write less code, which in-turn means less development time. Animations, transitions, data flow and a host of other things have all been simplified to be easier to digest and implement. Things that used to feel clunky and verbose are now clear and concise.

On top of this, Xcode includes a Canvas/Live Preview feature for SwiftUI projects which allows you to see UI changes without having to compile an app every single time you want to see changes made in your app. Canvas allows you to see multiple device previews at once, eliminating the time-consuming process of firing up a simulator each time you need to see your UI on a different device.

No longer do you have to worry about storyboard, .xib files, .nib files, and the headache of Interface Builder — SwiftUI does away with these, providing one simple source of truth. By removing all the complexity surrounding compiling and viewing UI, along with the time saved from writing less code, you’re able to deliver a product a lot faster.

Run into something you need from UIKit that isn’t in SwiftUI? No problem! Apple has provided the ability to implement UIKit elements in your SwiftUI project through the use of UIViewRepresentable and UIViewControllerRepresentable protocols. It also works the other way around — you can build SwiftUI views in an existing UIKit project.

Not only does this provide the flexibility of picking and choosing the best parts of each framework where you see fit, you’re able to minimize the risk associated with switching your project structure and development process. The transition from one framework to another comes with a lot less stress, and is less abrasive than having to choose one or the other.

One of the most impressive things about SwiftUI is how the core layout elements operate. Apple has done away with layouts like UITableView, UICollectionView, UIStackView, and replaced them with Stacks and Lists. These components are incredibly flexible, predictable, and require a lot less energy to produce great results. You’re no longer plagued by having to track down broken constraints, worrying if you’ve pinned a child element to its parent improperly, or the gotchas that come along with AutoLayout.

These components in themselves are quite powerful, but paired with the newest SwiftUI features shown at WWDC2020, the layout system has become even more robust and impressive. Apple has added support for lazy-loading Grid elements, which can adapt the number of columns in a grid to fit the space available, as well as lazy-loading Stack components for building highly-customized, scrollable layouts.

A lot of these features would be an enormous undertaking if you tried to implement them in UIKit, and it would be hard to match how well they work in SwiftUI. The layout system feels more present-day CSS on the web — it’s modern, responsive, and easily translatable to multiple device sizes and types.

Going forward, SwiftUI will be the future of development not only for iOS, but all Apple platforms. macOS, watchOS, tvOS all currently support SwiftUI development, and Apple has put a lot of time and effort into it — it’s not going away any time soon. Things like WidgetKit, the API used to develop the all-new widget feature on iOS 14 is currently only being made available to SwiftUI.

It’s an exciting time to make mobile apps, and with such a rapid progression of SwiftUI in such a short time, the future looks very bright. You can see more of the latest and greatest features that have been added to SwiftUI 

5  Reasons  Why  iOS  Developers  Need to  Switch  to  SwiftUI

Today we're talking to Gaurav Chandrashekar, a PM at PayPal with a ton of international experience at places like Spotify and Grab. Gaurav talks about his career journey as a PM, how to make big career decisions, and how to maintain a sense of wellbeing and motivation.

Thanks for joining us, Gaurav! It’s nice to connect. First up, can you tell us more about what you do at PayPal?

Sure! Long story short, I’m currently a PM at PayPal. I work on the banking partnership and payment experience team. I’m responsible for one of the ‘Add Card’ flows in the app, which is where users can link their cards by directly connecting their PayPal account to their bank (e.g. Bank of America, Chase Capital One, and so on).

From a user’s point of view, they’re looking to make a transaction — buying something with PayPal at checkout, making an in-store transaction by scanning with a QR code, or even paying with the cards in their wallet. Our core focus is to make sure nobody drops off when they have an intent to purchase.

Nice! How did you come to be in that role? What was your background, pre-PayPal?

Well, after I graduated I worked at Spotify for awhile. This was back in 2011, when it was still just based in Sweden. I learned from some amazing technologists there about how to build great software. It was really eye-opening, and I realized that you can have this global impact by building fantastic software and focusing a lot on the user experience.

I was really excited about entrepreneurship, so next I joined a startup with a couple of ex-Spotifyers who were focused on visual search. We didn’t achieve product market fit, but we moved to the US, and that was my introduction to North America and to Silicon Valley.

I was an engineer all through this time, and the startup experience taught me a lot. I was excited about technology, and as an engineer was thinking a lot about “okay, how do I build this?” I thought, if you build it, they will come. But I learned the hard way that this isn’t the case, after building things nobody used.

Next I wanted to think more about what problem was actually the right one to be solving. It sounds like an easy question to ask, but it takes a lot of effort and thought to really nail it. (I’ve learned a lot from people who focus on questions like this — folks like Shreyas Doshi and Marty Cagan.)

From there, I wanted to pick a place a little more long term, so I ended up choosing Singapore. It’s nice to be closer to family, and there are some amazing companies in the region. I joined Grab as a PM — it’s like Uber, in this part of the world. And then from there I ended up at PayPal. I love the global atmosphere at PayPal.

Awesome, you’ve lived in a lot of places. That’s a real series of adventures. What was the process like that allowed you to build your career at these different companies? And how did you make the decision to move from one to the next?

Great question. Earlier on, I was evaluating opportunities based on, “is this someone I’d love to work with as a manager, a teammate, a collaborator a colleague? Will this be something I’ll be excited to wake up every day and work on?” It was that simple. I also started thinking, “do I get to explore a different culture, a different country, a different way of life?” So that sense of exploration led me to Sweden, and New York, and Latin America.

And eventually, after building up a little experience, I was also asking myself, “is this is the kind role I can excel in? Is this where I want to spend time and grow my career?” Long term, I want to be somewhere that can demonstrate value as a business, and for customers. That makes it sustainable.

You can also join a startup, which is a little high risk because often you’re still trying to figure out the answers to those questions.

So that’s the framework I was thinking about, at a high level.

Ultimately it comes down to, which location, what stage of company, what kind of manager and culture do you want to be working with? And of course, compensation.

I built a career decision framework for myself, which I’ve shared with some friends and am happy to share here too.

That’s super helpful! So having lived and worked in so many different countries, you must have experienced a bunch of different business cultures, as well as differences company to company. Is there anything you’ve learned from these different business cultures that has been really helpful to you, or made you see things differently?

That’s a great question. I haven’t thought a ton about it, but one thing that stands out is that, having spent a couple of years in Sweden, I love the way they work for three reasons. One, they think about building technology in a long term way. You can see that from the likes of Spotify, iZettle (which is part of PayPal), Klarna, Skype, and so on. They had broadband internet pretty early on, which I think gave them a leg up when it comes to technology innovation.

The second thing is that they have a very good social safety net, so if you take a risk and it doesn’t work out, you’ll have support from the government, to some extent. It gives people more freedom to do whatever they want. They’re not as worried about, “oh no, I have to pay these bills right away, I can’t afford to focus on my creative pursuits.” And that’s a bit of a luxury. Maybe people can’t imagine the value that different systems of government can give you. So I think that’s something really beautiful.

And the third thing is, they really value work-life balance. I think that supports the mindset where they build things for the longer term — it’s not just about rushing to get things out in the next six weeks or for the next quarter. Instead, they’re really thinking through some of the bigger decisions and the impact those will have. So those things were really eye-opening for me in Sweden.

All that said, I find the common elements still remain the same from place to place at different technology companies, working in a very globalized environment. I don’t see very many differences in terms of processes and principles from one company to the next.

Personally, I seem to gel more with cultures that are global. At PayPal we have a pretty global team, that values diversity and inclusion, and I feel at home.

PayPal is such a big organization, how do that manage working as a global team?

Well, first of all, PayPal has been around for more than two decades. I’ve heard that some of the code that Max Levchin wrote 20 years ago still runs in production, which is amazing. What that means, I think, is that the culture has developed to think globally about platforms from the get go. It’s never a question of, “hey, can we launch this in Germany or Spain, immediately?” Instead, we think, “okay, if we do this, how would it impact the US, or Brazil, if we launched it in those countries?” And what’s cool about this is that often these questions come from engineering. They can see the truth in the code, and they know they’ll have to figure out what changes need to be made.

As a PM, it makes me really think on my feet, and think far ahead. The fact that we’ve built the systems over decades to think in this way — by default, thinking globally — allows us to have a big impact.

Some of it is changing, too. I sit in Singapore, and the development centre here was opened eight plus years ago. The team has been growing. In part, it’s an initiative to help make us available in different time zones, and not just focus our efforts in the US (although of course the US is one of our major markets).

But if you think about where we have to go next, where our next billion users will come from, they’re not going to be in the US or even in Europe. So there’s been a lot of focus on rapidly emerging markets, including APAC.

Good question. PayPal has a slew of product groups, including Crypto, Installments, and Credit, as well as others like BrainTree, IZettle, and Venmo that are also part of the group. I wouldn't be surprised if our core PM community internally is in the hundreds.

Do you find the function really different being part of such a large product team, as opposed to be on a small startup team?

It’s great that bring that up. My early experiences at startups were as an engineer. And I realized that I wanted to learn fundamental principles of product market fit, like, “how do you do user research? How do you synthesize it? What are the right questions to ask? What products should you build?”

And there are two ways you can really learn that. One is by joining a company that maybe seems to have product market fit, but it’s still unclear if it’s sustainable. It could be a startup or scale-up that’s taking off globally.

The other way is to join an established company with proven product market fit, where the question is more about what kinds of enhancements you can make, and what new products you can build on top of the existing ones, with the distribution channels and customers you already have.

Having spent time at scale-ups and now at PayPal, it’s clear to me that the principles of “how to build a product” don’t change. You ask the same questions, it’s just the mechanics of how you translate that into execution that change. The speed you work at changes a little. But the principles remain the same.

Absolutely. You started out as an engineer. Obviously many PMs come from an engineering background, and many don’t. If you were to offer advice to someone starting out, what would you tell them? Should they become an engineer first? How should they think about that question?

Yeah, I get this question a lot, and there a couple of ways I think about it.

One thing I love is the creative aspect of coding. I still do it today, on side projects. Running a small app on the side, or coding something to automate one of your own work processes — it’s great to be able to do, and it’s something I hope to still be doing 10 years from now. It gives me a sense that I can create something with mown two hands.

On the other hand, it’s not something I’d like to do full time. Having made the mistake of building things nobody used, I realized the value of a PM — trying to understand the problem, figure out if there’s business value, figure out what’s feasible and viable.

For me, as much as I love to code and spend time thinking about systems, I also love the value of communication. One of my mentors early on said, “I notice you’re starting to think a lot about some product thinking principles, why don’t you start to take on some fo that work?” In a startup, that’s very easy to do because there’s always more work. So I started doing that.

The technical knowledge really helps. It gives me confidence that I know what I’m talking about. At PayPal I see a lot of people who are technical in nature, which is amazing, because conversations are really effective then. But it’s a double-edged sword. I often find that when I’m talking to engineers, it’s very easy to think about how we’ll build something, and forget about the customer. At some point you have to remove yourself from the equation and say, “hey, look, these are the user problems.”

So I try to keep a little distance — I leave it to the engineers to figure out how they’re going to do it. I can say, “here’s the problem that needs to be solved, but you guys figure it out.”

What are some of the biggest challenges you’re facing in your role right now?

Well, there are a lot of stakeholders at PayPal, and the complexity of getting sign-offs increases when you have a lot of processes in place. This is a function of big organizations, it’s not specific to PayPal. But understanding these processes takes awhile. I’m still relatively new, so it can be hard at times, especially if you have a startup mindset where you want to hustle to get things done. So, working with a long list of stakeholders, I try to focus on breaking things down into Step 1, Step 2, Step 3, and having patience.

The other challenge is my timezone. A lot of our stakeholders are in San Jose, which is great. It keeps me connected to what’s happening in the Mecca of tech, essentially. But it means I have to think ahead a lot. I don’t want to miss a day, so I have to plan, and work hard to keep close stakeholders aligned. I’m always trying to be better at building that working relationship across teams, and across different timezones and regions.

One thing I do is keep a list of all my stakeholders, and I try to figure out what their communication style is. It’s not something they’ll always explicitly tell you, but it’s something you can learn for yourself. Do they respond on Slack? Are they more of an email person? Do they need nudges for you to get a response from them? So it’s just a model that you update as you continue to work with people, but it helps.

On Twitter you talk a lot about your internal approach to work. How do you think about maintaining your motivation, your energy levels, and your work life balance?

I started doodling recently and putting these diagrams up on Twitter, just about whatever I’m thinking about. It’s often to do with motivation, taking care of your mental health, productivity, and so on. It’s not specific to the PM role, but I think wellbeing is so important to take care of. Especially when there’s no differentiation between your work life and your personal life. I feel really privileged to be at a company like PayPal that really values wellbeing. It’s one of our core values. There are a lot of resources available to help you take care of yourself.

The other thing is, your ‘why’ can change. I’m always going back to, “why am I doing this role? Why am I at this company? What am I trying to achieve?”

For me, for instance, the common theme has always been that I really like working with the people I’m working with. Getting on calls energizes me. When I can solve a user problem, learn something new, launch something and start getting feedback, I really enjoy that process.

Great framing! Do you have a favorite app or tool that you’re obsessed with right now?

For me, it’s the Oura ring. It’s amazing. I love the app. I check it first thing every morning. It’s not because they have any new kinds of data. There are lots of fitness trackers out there. What they do really well is that package that content in a useful way. I love the user experience, and how they show you your scores. They also turn them into useful insights. They’ll say, “hey, did you drink alcohol yesterday that maybe affected your sleep?” Or “it seems like you’re sleeping later than usual, why don’t you prioritize your sleep today?” So the user experience, plus using the data to generate insights instead of just showing dashboards — it’s really cool.

I think you’ve convinced me to get one. Last but not least, have you read anything lately that you loved?

I’m reading The Almanack of Naval Ravikant, by Eric Jorgensen. It’s amazing, it’s so succinct. I’ve followed Naval for awhile, but I love having this info in book form because I can read a little and let my mind wander and think about how I can apply it to my life, as opposed to just continuing to scroll on Twitter.

Excellent recommendation. Thanks so much Gaurav, we really appreciate you taking the time!

For more from Gaurav, follow him on Twitter, and check out his personal website, Doodling between meetings. Want more Product Thinking interviews? Drop your email in the newsletter box below.

Input Output

An interview with Rishi Tripathy

This week's links:

App Store Optimization tips for your product launch

5 Reasons Why iOS Developers Need to Switch to SwiftUI

An interview with Emma Townley-Smith

An interview with Paul Ortchanian

An interview with Gaurav Chandrashekar

An interview with Andrew Yu

An interview with Den Delimarsky

Starting your Django project on the right foot

How to launch a startup without a technical cofounder