Mobile developer personas
The most significant event in the world of tech over the past decade has been the move to mobile. Businesses and consumers have leveraged the ubiquity and usability of mobile applications to change the world. With the proliferation of SaaS API startups, the mobile developer persona has become an important customer segment. This post will introduce essential mobile developer personas and developer experiences (DevX) that serve these personas. There's an infinite number of vectors at play in defining personas. I'll intentionally leave out vectors like company size and how that affects these personas as an exercise for the reader. You’d also see that the personas lead to competing developer experiences, which you’d need to reconcile in practice.
Harini, the Hacker
She's an Android operating system expert but is less familiar with iOS.
Loves to get the job done quickly, including making quick and dirty fixes.
Jumps in to "save the day" in an all-hands-on-deck situation.
Well-versed with technology in and outside of their daily work routine.
Deeply optimizes personal productivity.
DevX for Harini
Keep up with the ecosystem. Allow customers to use your product alongside the latest and greatest tech. Absorb OS/Build Tool API changes, keep dependencies on the bleeding edge, and support multiple distribution mechanisms for binaries.
Open source as much of your product as you can. Harini likes to report and fix bugs.
Optimize for easy onboarding over configurability.
Build community forums on Slack or discord that allow fast responses to customer questions.
Build a control plane API layer so your customers can automate /script administrative operations and improve their productivity.
Taylor, the Tech Lead
Taylor Understands the Apple (iOS, macOS, WatchOS, tvOS) and Android operating systems at good (but not great) depth.
Is familiar with all of the projects going on in their team. Needs to have oversight over a variety of independent projects.
Optimizes for software quality and stability, even if it means shipping a bit later.
She jumps in to troubleshoot her team's problems.
Updates internal documentation frequently.
Cares about how the product is affecting business metrics
DevX for Taylor
Be flexible about how your APIs are consumed - Build tools, programming languages, dependency injection frameworks, etc. Taylor likes optionality and is always worried about lock-ins.
Offer High-quality (paid) support channels.
Publish extensive release notes and documentation for APIs.
Improve the stability of your offering. Focus on bug fixes and crashes.
Support usage of your product from the customer's dev, staging, and prod environments.
Provide telemetry alongside business metrics by building integrations with Analytics and Observability provider APIs.
Reduce the number of breaking changes to your APIs to minimize the cost of migration for the team.
Be clear about data collected by your APIs and the implications of that in different geographic locations.
Navya, the Newbie
Navya has been professionally building software for < 1yr.
Loves to be self-sufficient and not have to ask Taylor for help.
She loves to learn new tech and level up her knowledge.
She wants to build a startup of her own in the future.
DevX for Navya
Provide clear examples and quickstart projects to demo how she should use your APIs.
Log clear error messages.
Maintain stack overflow questions. For common integration mistakes, self-document Stack Overflow questions and answer them.
Offer "coursework" through Coursera to help them upgrade their skill sets.
Build "Drag and drop" experiences before programmatic configurability.
