Web Apps vs Music Tech & Creative Tools — Product Mindset

Advertisement:

web-app-vs-music-tech-product-mindset

When people who have experience building & scaling web apps come to making music tech apps, they bring some baggage & traits along that can be counterproductive. Here are a few: 1. Unnecessary focus on retention time – The whole point of music tech apps is to enable artists to create. How much time they spend creating is a personal choice. The YouTube / Instagram / Duolingo & free-to-play games philosophy of keeping users on the platform for as long as possible, is driven by the fact that more time = more space to show ads. This does not link well to creative tools. If the user is spending more time on a creative tool in terms of struggling to figure out how it works, then the tool is not fulfilling its purpose. 2. Attention seeking strategies – The SEO culture forces website makers to always be in the mindset of 'how can we get users on our website?' This translates into avoidable & ineffective influencer-driven advertisements with clickbait titles. And a ton of Category-Marketing with messaging such as "Sound is important for your films & games" etc, instead of showcasing the advantage that the product brings. 3. Agile iterative build-in-a-hurry product cycles – Deploying on the web is the easiest thing in the world. Anyone denying it is likely safeguarding their jobs. Click a button, inform the user to hard refresh and you're good to go. Building plugins, apps & music tech tools requires intense testing. You cannot just ship something in a week and then ship it again next week and then again the week after and then keep doing this till eternity. Or can you? Unfortunately, a lot of the ML world lives in the web & APIs. A very few who do experiment on-device options live a lot in Max; a good starting point but not enough. 4. Limited vision to use multi-window UX – You can only do so much in a browser tab, and this becomes second nature for most product creators. They might miss to acknowledge that there's more to life than one-element-at-a-time pattern. The mindset is that ‘going-away from their web page’ = 'the user lost interest in our app'. Background processes are legal in native apps. Use it please. So how can we change this? One option is to experience native apps first hand, right from downloading & installing to using with CPU-intensive aspects of it, to really see the limitations of the web. What are other strategies that come to your mind? Let me know in the comments or using the contact form. Share this post with anyone who can benefit from taking a step back and retrospecting.