Category Archives: Product Development

False Economies – if it’s cheap, there must be a reason!

Posted on by
Reply

When I was 7 or 8 years old, I asked my parents to buy me a specific brand of toy as a birthday or Christmas present. With the best of intentions, they chose instead a close approximation of the real thing – presumably because it was cheaper, and to them it was exactly the same. Of course, being cheaper, it was badly designed, poorly made, and was nothing like the toy I had asked for. From memory, it only lasted only a few months before falling apart.

This was my first lesson in false economies – cheap and cheerful can quickly become cheap and nasty, rather like some cheaper brands of peanut butter, which are bulked out with sugar, oils, fats and other additives (instead of containing 100% peanuts).

Many years ago I had some shirts made in Shenzhen, because they seemed like a bargain. Sadly, another false economy – after I got them home, I realised the cut was all wrong, and I’m sure they had substituted a cheaper fabric to the one I had chosen. They were unwearable. On the other hand, some jackets I had made in Hong Kong lasted nearly twenty years, because I had paid a bit more to go to an established tailor.

I’m not saying that more expensive branded goods and so-called luxury items are always “better” – but as a general rule, when doing like-for-like comparisons, you get what you pay for. When an item costs more to buy, it invariably lasts longer because of the materials used, the better design, the superior manufacturing and the overall higher quality.

I appreciate that in the current economic environment, consumers are even more cost conscious, and are looking for value for money, if not actual bargains. But just because something is cheap, doesn’t mean it’s the better option. Look at the true cost of fast fashion, fast food, fast money…

Next week: The Law of Diminishing Returns….

Apple, iOS, and the need for third-party innovation

Posted on by
Reply

A main use of my iPad is creating music. In my experience, iOS has provided a convenient and relatively low-cost way to explore and experiment with music synthesis, sampling, looping, audio processing, programming, sound design, production and dissemination of my semi-amateur home-studio recordings. The numerous developers involved in creating music-related apps have produced some of the most innovative products available.

At times, these developers have pushed the envelope when it comes to app design, functionality and interoperability. Even though many of these developers are involved with the design and production of hardware instruments and technology, and writing software for laptop and desktop computers, they also recognise that the iPad offered another way to interface with digital music tools. In some cases, iPad apps can connect to or interact with their hardware and software counterparts (e.g., touchAble).

Elsewhere, developer vision has pre-empted and even overtaken Apple’s own product design. A good example is IAA (Inter-App Audio), introduced by Apple in 2013. While some app developers were quick to adopt this feature into their own products, in the same year the team at Audiobus took this functionality to another level, with a fully integrated platform within iOS that allows multiple apps to be connected virtually. Eventually, in 2019, Apple countered by upgrading their own Audio Unit (AU) infrastructure that introduced another way to connect separate apps.

There remain some anomalies in Apple’s approach to competing music apps and their commercial models. Although Apple has enabled developers to offer in-app purchases and upgrades, it is noticeable that to this day, Bandcamp does not sell digital music via its mobile app (thought to be due to Apple’s hefty sales commission on digital content?); but Bandcamp customers can purchase physical goods via the app. While over on the SoundCloud app, users can purchase in-app subscriptions offering ad-free streaming and off-line content, but Spotify customers cannot purchase similar premium streaming services within the corresponding app.

The latest move from Apple has got some developers quite excited. As well as bringing its professional video editing suite, Final Cut Pro, to iPad, Apple has launched an iPad version of Logic Pro, its professional music DAW (Digital Audio Workstation). Now, I don’t have a problem with this, and I can see the attraction for both app developers and Logic Pro users.

I myself use Ableton Live (and not Logic Pro or Apple’s consumer-level product, GarageBand), so I am not planning to add another desktop DAW. Besides, Ableton enables third party developers to integrate their AU and VST plug-ins on Mac. In addition, Ableton has launched a mobile app, Ableton Note, that can interact with the desktop program, which just confirms the co-existence of these platforms, and user preference for interoperability.

My concern is that with the introduction of Logic Pro on iOS, Apple may close off some inter-app functionality to third party apps if they do not support integration with Logic Pro. We’ve seen the way Apple can shut down external innovation: without getting too technical, until 2021, and with a little effort, users could run iOS music apps on their Macs, and within DAWs such as Ableton. Apple then closed off that option, but more recently has enabled iOS-derived AUv3 plugins to run on M1 chip-enabled Macs.

Hopefully, Apple recognises that an open ecosystem encourages innovation and keeps people interested in their own products, as well as those from third-party developers.

Next week: Crown Court TV

App Overload

Posted on by
Reply

Following a recent upgrade to Apple’s iOS software, I found myself forced into some serious housekeeping on my iPad. I hadn’t realised how many dormant apps I had accumulated over the years, so I took the opportunity to do some culling.

First, there were apps that could no longer be accessed from the app store. These are programs that have been removed by their developers, or are no longer available from the Australian app store (yes, even in this digital day and age, geo-blocking still exists). I estimate that these accounted for about 20-30% of the total apps I have ever downloaded.

Second, apps that are not supported by the current version of iOS, because they have not yet been updated by their developers. (Luckily, I keep an older version of iOS on a separate iPad, which can allow me to retrieve some of these apps via some digital archeology.) These represented another 15-25% of my apps (a variable number, given that some of them may get upgraded).

Third, apps that I seldom or never use. Thankfully, the iPad Storage settings provide the “Last Used” date, but don’t enable users to rank by chronological use (or by frequency of usage; the “Search” function within Storage only lists apps alphabetically). Perhaps Apple can refine the Storage Management to help users better manage over-looked/under-used apps? Anyway, these forgotten or neglected apps accounted for another 25-30%.

In total, I estimate that up to 75% of my iPad apps were redundant, through disuse, obsolescence or inaccessibility. Research shows that 25% of apps we download are only used once, so unless these are free products, it feels like a large chunk of the US$900+ bn in app purchases could be going to waste…

Next week: Apple, iOS, and the need for third-party innovation

 

 

No-code product development

Posted on by
Reply

Anyone familiar with product development should recognise the image below. It’s a schematic for a start-up idea I was working on several years ago – for an employee engagement, reward and recognition app. It was the result of a number of workshops with a digital agency covering problem statements, user scenarios, workflow solutions, personas, UX/UI design and back-end architecture frameworks.

At the time, the cost quoted to build the MVP was easily 5-6 figures – and even to get to that point still required a load of work on story boards, wire frames and clickable prototypes….

Now, I would expect the developers to use something like a combination of open-source and low-cost software applications to manage the middle-ware functions, dial-up a basic cloud server to host the database and connect to external APIs, and commission a web designer to build a dedicated front-end. (I’m not a developer, programmer or coder, so apologies for any glaring errors in my assumptions…)

The growth in self-serve SaaS platforms, public APIs and low-cost hosting solutions (plus the plethora of design marketplaces) should mean that a developer can build an MVP for a tenth of the cost we were quoted.

Hence the interest in “low-code/no-code” product development, and the use of modular components or stack to build a range of repetitive, automated and small scale applications. (For a dev’s perspective check out Martin Slaney’s article, and for a list of useful resources see Ellen Merryweather’s post from earlier this year.)

There are obvious limitations to this approach: anything too complex, too custom, or which needs to scale quickly may break the model. Equally, stringing together a set of black boxes/off-the-shelf solutions might not work, if there are unforeseen incompatibilities or programming conflicts – especially if one component is upgraded, and there are unknown inter-dependencies that impact the other links in the chain. Which means the product development process will need to ensure a layer of code audits and test environments before deploying into production.

I was reflecting on the benefits and challenges of hermetically sealed operating systems and software programs over the weekend. In trying to downgrade my operating system (so that I could run some legacy third-party applications that no longer work thanks to some recent systems and software “upgrades”), I encountered various challenges, and it took several attempts and a couple of workarounds. The biggest problem was the lack of anything to guide me in advance – that by making certain changes to the system settings, or configuring the software a certain way, either this app or that function wouldn’t work. Also, because each component (the operating system, the software program and the third party applications) wants to defend its own turf within my device, they don’t always play nicely together in a way that the end user wants to deploy them in a single environment.

App interoperability is something that continues to frustrate when it comes to so-called systems or software upgrades. It feels like there needs to be a specialist area of product development that can better identify, mitigate and resolve potential tech debt, as well as navigate the product development maintenance schedule in anticipation of future upgrades and their likely impact, or understand the opportunities for retrofitting and keeping legacy apps current. I see too many app developers abandoning their projects because it’s just too hard to reconfigure for the latest system changes.

Next week: Telstar!