post

B2B product management

Artificial Intelligence (AI) & Machine Learning (ML)

Building Product Teams

Business Strategy

Data Driven Product Management

Digital Transformation

Diversity and Inclusion

Minimum Viable Product

OKRs

Prioritisation

Product Design

Product Research

Product Development Process

Product Ethics

Product Discovery

Product Leadership

Product Management Career

Product Strategy

Stakeholder Management

🌎 <a href="https://www.mindtheproduct.com/world-product-day/" style="color:#FFFFFF;text-decoration:underline;">Happy World Product Day!</a> Be sure to celebrate product, yourself, and your peers today! 🎉

Successful product management in companies where it’s least understood

Measuring critical user journeys – Javier Andrés Bargas-Avila (UX Director, Google)

A new way to look at applied experiments

Product survey findings: Only 15% of users are embracing AI features 

Building high-performing product teams: The PDLC approach

Footer About

Footer Contribute

Footer Get Involved

Footer Links

Mind the Product

Guest Post

Overcoming the 20% feature usage challenge

Product Management

Three product leaders to learn from at #mtpcon inside Pendomonium

Paul is the founder of Unlock, a boutique consultancy that helps clients achieve product-market fit. During his career, Paul has helped launch over a dozen breakthrough products that had no clear precedent and uncertain demand. His experience spans Fortune 50 companies such as Microsoft, Sony and Adobe along with venture-backed startups. Paul has also founded five of his own startups with two exits.

Paul Shustak

<p>In 2010 Google announced it would prioritize mobile ahead of desktop when developing new products. As we all know, there’s been a massive shift toward mobile-first product design since then. Conventional wisdom now tells us that it&#8217;s almost always best to start with mobile, because the success of your business ultimately depends on its ability to attract and retain users with an app.</p>
<p>But there are cases where the conventional wisdom should be ignored. Our product, <a href="http://www.karen.care/" target="_blank" rel="noopener noreferrer">Karen</a>, was one of those. We knew that an awesome mobile experience would be crucial to our long-term success, but we intentionally focused our design and development efforts on the desktop first, investing in mobile only after users told us we had met their desktop needs. This approach enabled us to arrive at an optimal design faster and more cheaply than we could have with a mobile-first strategy. It wasn’t an easy decision, but in retrospect it was the right one. In this article, I’ll share the key reasons we took this approach and how we benefited.</p>
<h2>The Product</h2>
<p>Karen is a SaaS platform that helps families to care for elderly parents and relatives. The product has three pillars:</p>
<ol>
<li>Action plan – Users fill out an onboarding survey which enables Karen’s algorithm to generate a custom Action Plan consisting of recommended tasks that can help them save money, time and improve health outcomes.</li>
<li>Collaboration – Families can divide and conquer on their Action Plans with collaboration tools that enable them to assign tasks, set reminders, comment, share files, etc. They can also create custom tasks that the algorithm may have missed.</li>
<li>Expert help – Families can find and collaborate with the appropriate expert for each task without leaving the app.</li>
</ol>
<p><img loading="lazy" decoding="async" class="aligncenter size-full wp-image-13902" src="//wp-content/uploads/2018/09/karen-1.jpg" alt="The dashboard of the Karen app" width="2400" height="1600" srcset="/wp-content/uploads/2018/09/karen-1.jpg 2400w, /wp-content/uploads/2018/09/karen-1-300x200.jpg 300w, /wp-content/uploads/2018/09/karen-1-768x512.jpg 768w, /wp-content/uploads/2018/09/karen-1-1024x683.jpg 1024w" sizes="(max-width: 2400px) 100vw, 2400px" /></p>
<h2>The Company</h2>
<p>As a startup on a tight budget we had three key requirements for our development process:</p>
<ol>
<li>Build cheaply – We didn’t know how many release cycles it would take to reach product/market fit. Therefore, preserving capital was hugely important.</li>
<li>Iterate quickly – Everyone on the team had experience caring for an elder, which gave us a great head start in terms of understanding our users. But we also knew there were limits to our knowledge. Therefore, rapid learning and iteration would be crucial to our success.</li>
<li>Make data-driven decisions &#8211; With limited runway, we knew we couldn’t risk making bad guesses; every major design decision had to be validated by data.</li>
</ol>
<p>Given the cost and friction of mobile development, these requirements already hinted that a desktop-first approach might be the better choice.</p>
<h3>Step 1: Customer Discovery</h3>
<p>Even though our team had caregiving experience, we knew it was important to validate our assumptions by interviewing other caregivers. This process made it clear that we were on the right track with our three pillars, but there was also a lot of uncertainty about how to implement the workflow and interaction details. Getting these right would be crucial and could take numerous iterations –  a realization that pushed us further toward a desktop-first approach.</p>
<h3>Step 2: Development of User Hypotheses</h3>
<p>We then developed a set of core hypotheses related to the mobile vs. desktop decision. These cemented our decision to prioritize desktop. They were as follows:</p>
<ol>
<li>Karen would resonate most with a 45 to 55-year-old female knowledge worker – a group which makes up a large percentage of caregivers in the US and likely to be an early adopter of a tech-centric solution like Karen.</li>
<li>Usage would fall into two general modes: planning and day-to-day management. For example, the decision to move into an assisted living facility would likely be planning task; filling a prescription would be a management task.</li>
<li>Users would accept &#8211; and perhaps even prefer &#8211; performing planning tasks on the desktop because these require focus and contemplation, something a tiny screen used on-the-go doesn’t support very well.</li>
<li>Due to the round-the-clock nature of caregiving, users would frequently access Karen from their work PCs and laptops.</li>
<li>Compared to a user in their teens, 20s or 30s, our target user would be relatively forgiving if we lacked a mobile app.</li>
<li>Since none of our high-priority use cases required device layer APIs such as geolocation, camera, or accelerometer, we could support on-the-go usage with a responsive web app.</li>
<li>It was possible – and perhaps even likely – that each family would contain a mix of Android and iOS users. Therefore, we would need to build apps for both platforms in order for families to collaborate natively on mobile.</li>
</ol>
<h3>Step 3: Build/Validate/Iterate</h3>
<p>Because we we were developing for the web, we were able quickly release an MVP. The feature set was limited, and the design was rough, but it was sufficient to begin testing our hypotheses. We used interviews, usability tests, analytics and test marketing campaigns in an attempt to validate as many as possible. The data told us we were on the right track with our desktop-first approach. It tooks several more release cycles but we were ultimately able to validate all of the hypotheses and arrive at a highly usable and engaging desktop design. In retrospect, it probably would have taken twice as long, and cost twice as much had we started with native mobile.</p>
<h3>Step 4: Mobile Development</h3>
<p>We are now translating our desktop product into a mobile app. This hasn’t been a straightforward process by any means. We’ve had many internal debates about the feature set, workflow and screen layout, but the learning we’ve acquired on the desktop has given us the confidence to make what we think will be the right decisions for mobile. We also have the benefit of a user base we can turn to for feedback.</p>
<h2>Conclusion</h2>
<p>Mobile-first is a no brainer for many products, but yours may not be such a clear-cut case. Before deciding, ask yourself the following questions:</p>
<ol>
<li>Does your target user live on mobile or do they divide their time between platforms?</li>
<li>Do you know your user well enough to deliver a great user experience on the first or second release?  If not, does your timeline and budget afford you the luxury of iterating over multiple releases?</li>
<li>Do your key use cases require a native mobile experience, or is mobile responsive good enough?</li>
<li>Can you attain product/market fit with either an iOS or Android app, or will you have to release both versions simultaneously?</li>
</ol>
<p>If the answer to most or all of these questions is “no,” then you are probably are better off focusing on desktop first.</p>
<div class="g g-21"><div class="g-single a-170"><a class="gofollow" data-track="MTcwLDIxLDEsNjA=" href="https://www.pendo.io/pendomonium/"><img decoding="async" src="https://www.mindtheproduct.com/wp-content/uploads/2024/06/MTP-Footer_ad.png" /></a></div></div>

core/freeform

Common transformation pitfalls by Marty Cagan

Using principles to make better decisions faster by Martin Eriksson

How to build for creators by Peter Yang

How to navigate tricky work relationships

Organizing around complex products at the intersection of physical and digital by Matthew Cornford

Mobile Second: When Desktop is the Right Platform to Focus on First

Paul Shustak

Comments

Read next