The Client: pdftools / Smallpdf

Smallpdf (acquired by pdftools) was born in 2013 in Switzerland and provides a simple, secure, and reliable answer to the world’s PDF challenges with over 20 PDF tools. The platform is designed to be user-friendly and intuitive, with a focus on simplicity and efficiency.

During these 10 years, they have helped over a billion users in 195 countries (even in Antarctica!), and it’s available in 24 languages.

Some of the key features of Smallpdf include file conversion, PDF editing, compression and protection, E-Signatures, and OCR (Optical Character Recognition).

Smallpdf's services are available for free, but there are also premium features that require a subscription. For example, premium subscribers can access features such as batch processing, which allows users to convert or process multiple files at once, and offline access, which allows users to work with PDF files even when they are not connected to the internet.

‍

The Mission: Interim Product Manager

We joined Smallpdf for 6 months during a paternity cover. They had just decided to develop the first app within a suite of new apps. The app would focus on the physical-to-digital document creation space. We were brought on board to lead the discovery effort. The goal of the app was to generate significantly more annual recurring revenue than the existing, multi-purpose app.

The team consisted of one Engineering manager, four senior iOS developers, and three senior Android developers but lacked a dedicated designer when we joined, although we were supported by the UX research team and an external designer. The developers had very little discovery experience. Our challenge was not only to discover the right app to build but also to help the development team grow in terms of user-centricity and discovery skills. Lucky for us, the team was eager to learn.

Company Expectations:

• Discover the biggest opportunities within the digital-to-physical documentation space.
• Create an app that addresses these needs and has the potential to meet the company’s ARR target
• Be ready in time for the seasonal wave of new sign-ups and subscriptions to maximize the impact of a marketing campaign

‍

Our Main Quest

Launch: Onboarded Very Fast

We had 2 weeks of overlap with the Product Manager before he went on paternity leave. We used this time to learn as much as we could about the existing app, user base, tracking setup, and past research. Anything that could give us a head start in our discovery efforts. After two weeks, we were all caught up and eager to start discovering.

Explore and Conquer: Solving for the Client

We interviewed multiple users from the micro-business segment (our targeted segment) who digitize documents frequently (at least once per month). We identified the main pains, needs, jobs, and desires by analyzing the interviews and created an Opportunity-Solution Tree from the insights. The highest-level opportunities we identified were around:

• The act of scanning & digitizing documents
• The need to manipulate scanned documents
• The need to organize scanned documents
• The need to share scanned documents

Prioritizing Opportunities

The insights from the interviews were good, but we had too much uncertainty to determine which opportunity to pursue. We decided to:

• Perform a competitor analysis to identify potential differentiators
• Conduct an Opportunity Scoring survey to identify underserved needs

We approached the competitor analysis from multiple angles:

• A general assessment of free and premium features, price points, independent reviewers, and app store reviews
• Our assessment of the scanning capabilities of the various apps
• A heuristic evaluation of the UX and UI.

The general conclusion was that there were opportunities to create a better user experience and to provide premium features at a lower price point, so we had our initial positioning strategy: Premium features with a clean and simple UX/UI (one of Smallpdf’s strengths) at a competitive price point

The opportunity scoring was repeated twice, once with users of the existing Smallpdf app and once with users of the Smallpdf web product. We identified two underserved needs that we prioritized and several over-served needs that we rejected.

Now that we had our initial positioning and opportunities, it was time to come up with solutions that solve the needs

‍

Tackling Our First Leap of Faith: Our Solution Solves the User’s Need

Together with the team, the external designers, and one of the UX researchers, we organized an ideation workshop to identify solutions. We started by creating a high-level user journey to represent the workflow users described to us during the interviews. Everyone created their flow, which we then reviewed and combined the flows to create a common understanding of the existing user journey.

We used this journey to identify opportunities to simplify the workflow, focusing on the two core needs that we identified. To avoid influencing each other, we started brainstorming on our own using crazy 8s as a framework. We went through several rounds of brainstorming and presenting before we voted on the best ideas. We ended up with three ideas that we turned into low-fidelity wireframes and tested with users.

One of the concepts was well received by users, but it was clear that the “aha” moment was missing from the journey. The needs we were solving were focused on saving time, but that value would only become apparent after several uses. With apps, if you don’t show the value in the first interaction, the risk of a user uninstalling is high. We needed to add a clear aha moment to our concept. To do this, we added the third most underserved need to our scope.

This need was around cleaning up poorly scanned images, something highly visual with immediate feedback to users. We went through another round of ideation for this need and tested seven concepts with users. One concept was the clear winner and provided users with that “aha” moment.

After one more round of concept testing, where we combined all the concepts and created three variations with different flows, we settled on a winner. We were confident that our concept would solve the user’s need. But would they be willing to pay for it? And would they be willing to abandon their existing solution and switch to ours?

‍

Tackling Our Second Leap of Faith: Willingness to Pay and Switch

At this stage of our discovery, we were pretty confident that we were solving a need that users had and that our solution solves their needs. However, we weren’t confident that users would switch to our solution since the market was crowded. We were also not sure if the need was so big that users were willing to pay for our solution. To gain more confidence, we ran a short survey.

Users were shown a video of our concept after which we asked them about their willingness to pay using the van Westendorp pricing model. The Westendorp model is very effective in gauging consumer sentiments surrounding a potential range of prices, and it reduces the bias introduced when asking users directly for a single price point.

One benefit of this method is that we didn’t have to guess about reasonable prices before asking users. The range also helped us understand the potential highest and lowest price points, giving us the flexibility to set a price within the range while considering competitor pricing. After the video and pricing questions, we asked users about their current solutions, how satisfied they were with the current solutions, and how willing they were to switch to our solution.

The results were mixed; the price range for all users was higher than we expected, but the willingness to switch was lower than we hoped for. Luckily, we added segmentation questions to the survey, so we dug into the details and identified 4 potential segments.

‍

MVP - Leap of Faith #3: Product Stickiness and User Activity

At this point in our discovery, we learned everything we could without building anything. It was time to spend 2 sprints (about 4 weeks) building an MVP and providing it to 50 users so that we could gather behavioral insights around the stickiness, habits, and engagement of the segments that we identified. In parallel, we planned to assess the market potential of the segments we identified.

We kept things simple by focusing on the iOS app, reusing solutions from the existing app, and using SDKs and open-source solutions. The goal was to learn from users as fast as we could but also to throw things away if they didn’t work. When we handed over to the returning PM, the team was in the last week of development. We’re looking forward to a future release (or not) of this app.

Managing the process as an OST

We ran our discovery using continuous discovery habits as a starting point. We set health metrics within our OKRs around the number of user touchpoints to hold ourselves accountable. Through the process, we built and maintained the opportunity solution tree shown below. We started by identifying the opportunities and the parent-child relationships between various opportunities, discarding ones that did not contribute to our main product goal. Once we started working on our solutions, we started adding the solutions and experiments to the tree. We used tags and colors to visualize which opportunities and solutions were prioritized, which experiments passed or failed, and which solutions were discarded as a result. The OST formed the summary of all our discovery work, but also as the entry point for further exploration because we linked the experiment cards to relevant Jira tickets or Notion pages. This helped us keep track of what happened and what we needed to do, but also gave stakeholders a simple-to-digest format to understand where we were in our discovery journey.

‍

Side Mission: Increasing the Developer's Discovery Skills

The engineers in our team were highly skilled in building solutions, but they had limited experience in discovery practices. During our time at Smallpdf, we worked on increasing the team’s skills and ability to manage the discovery process. This was important because the team had to continue discovering after we left. To facilitate this, we:

• Held an interactive Continuous Discovery workshop to teach the team about discovery
• Included the Engineering Manager in our Product Trio to train him more thoroughly in discovery, but also to make sure the engineering perspective was represented
• Set up a weekly Ask me Anything with the developers - this became greatly appreciated by the team because it gave them a stage to raise their concerns and to learn why we were doing what we were doing. These sessions helped bridge the gap between the engineering team, product, and the wider organizational context (strategy, vision, etc.)
• Included one developer every time we talked to a user.

When our journey with Smallpdf came to an end, the team was thinking about the user needs, questioning our approach, and suggesting alternative paths, and actively looking for assumptions that needed to be validated, plus the experiments to validate them.

‍

Mission Achievements: Delivered Outcomes

💡 Discovered and validated opportunities and solutions within the physical to digital document creation space with enough confidence to invest in an MVP

💡 Created a team habit of 1.5 user interactions (interviews, surveys, etc.) per week

💡 Upskilled the development team so that they know what discovery is and can run their discovery process together with the returning PM

‍