No-code product development

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!

 

 

 

The new productivity tools

With every new app I download, install or have to use, I keep asking myself: “Do I feel more productive than I did before I downloaded it?” Comparing notes with a business associate the other week, I realised that the arsenal of daily tools I use continues to expand since I last blogged about this topic. At times, I feel like Charlie Chaplin in “Modern Times” trying to keep on top of this digital production line.

Image sourced from Wikimedia Commons

In particular, the number of communication tools (instant messaging and conferencing) keeps growing; document and file management continues to be a battle largely between operating systems; and most collaboration tools struggle to make the UI as seamless as it should be – so that the UX is all about the “process” for creating, updating and maintaining projects, and not the quality of outcomes.

So, as an update to my previous blog, here’s a few thoughts on recent experiences:

Meetings/Chat

Added to my regular list are Telegram, WeChat, UberConference, BlueJean and RingCentral. Meanwhile, Microsoft (Skype), Google (Hangouts) and Apple (FaceTime) all compete for our communications. (Even Amazon has its own conferencing app, Chime.) One of the biggest challenges I find is browser compatibility (when using via a desktop or laptop) – presumably because vendors want to tie you into their proprietary software eco-systems.

Project Management/Collaboration

Still looking for the perfect solution…. Products are either so hard-coded that they are inflexible, or so customisable that they can lack structure. I suspect that part of the problem is projects are still seen as linear (which makes sense from a progress and completion perspective), but we collaborate at multiple levels and tasks (with corresponding inter-dependencies), which don’t fit into a neat project timeline.

Document/File Management

I seem to spend most of my day in Google Drive (largely thanks to Gmail and Drive) and Dropbox (which continues to improve). I find Dropbox more robust than Google Drive for file management and document sharing, and it continues to expand the types of files it supports and other functionality. Whereas, with Drive, version control is a bit clunky, unless the document was first created in Google Docs.

Productivity

Overall, Google Docs is still not as good as MS Office (but does anyone use OneDrive, let alone iCloud/iWorks, for document sharing or collaboration?)

One thing I have noticed is that my use of native iOS productivity tools has dropped off completely – if anything, I am now using more MS Office iOS apps (e.g., Lens, OneNote), and some Google Docs apps for iOS. Plus the DropboxPaper iOS app.

CRM

I’m starting to use Zoho (having outgrown Streak) – and I’ve heard that there is even a Zoho plug-in that connects with LinkedIn, which I shall soon be exploring. But as with Collaboration tools, getting the right balance between rigidity and flexibility is not easy.

Next week: The first of three musical interludes….

 

Gigster is coming to town….

Melbourne’s Work Club recently hosted Gigster Senior Project Engineer, Catherine Waggoner, in conversation with Venture-Store’s George Tomeski. Part of Startup Victoria‘s Fireside Chats, it likely herald’s Gigster opening an office in Melbourne, to service local clients and to tap into the local developer community.

gigsterFor the uninitiated, Gigster describes itself as the “world’s engineering firm”, that helps clients scope, design and build software, apps and digital products. Using an established product development methodology, and drawing on the resources of a 1,000 strong network of freelance designers, developers and product managers, Gigster is taking much of the pain out of the costing and requirements process for new projects, as well as building a growing client base of enterprise customers.

Not mincing her words, Ms Waggoner opened her remarks by commenting, “The software development industry model is f*#$ed”, because:

  • Requirements are poorly defined
  • Scoping is laborious
  • Development costs blow out, and
  • The whole process is not very transparent and not very accessible.

As a case in point, she mentioned the significant cost disparity between what some digital design agencies or app studios might quote for building an iOS product compared to what Gigster would estimate. By: breaking projects down into the distinct stages of scoping, design and pre- and post-MVP; only engaging the “best of the best talent”; using proprietary tools both to estimate fixed rate costs (rather than billable hours) and to define and source solutions; and re-using content from a library of “Community Software” resources, Gigster is able to deliver quality projects in shorter time, and on more modest budgets. For example, based on the large number of projects that they have fulfilled, their “Gigulator” estimating tool incorporates 5,000 possible features.

From an investor perspective, Mr Tomeski mentioned that the “VC inflexion point is getting much earlier” in tech startups. Meaning, with lower development costs (and potentially, reduced valuation multiples), investors are looking to get in sooner, with lower exposure, but still generate reasonable returns on exit, thanks to cheaper establishment costs.

Of course, Gigster sits at the heart of the gig economy, a huge issue when it comes to discussing the Future of Work. Interestingly, many of Gigster’s contractors are themselves startup founders, who freelance while building their own businesses. But such is the strength of the network, something like 35%40% of their contractors work full-time for Gigster – they like the flexibility combined with the continuity. Many of the contractors are referrals from existing team members, and a number of teams (known at Gigster as “houses” – presumably a frat thing?) have bonded to such an extent that they get allocated specific projects to work on together, even though they themselves may be working in different locations, based on previous projects.

Working for Gigster is probably a career choice for some contractors, because there is a variety of projects to work on, and the opportunity to be involved from start to finish. Which may be the opposite if working in a more corporate or enterprise environment, where work may be routine, repetitive and reasonably narrow in scope.

If Gigster does decide to set up shop in Melbourne (with encouragement from
InvestVictoria) they will be joining the likes of Slack, Stripe and Square, tempted by financial and other incentives. Such a move may challenge a number of local digital agencies, who will face even more competition for talent and customers.

According to Ms Waggoner, enterprise clients represent 40% of the business, and should comprise 60%-80% very soon. Not only that, but the average deal was initially $15k, now it’s more like $100k. However, enterprise clients have a much longer sales cycle. Plus, many innovation teams within enterprises are more like loosely formed groups of niche experts, so they need training on how to think like a startup. When you consider the greater dependency on legacy software by corporate clients (where it may make financial sense to retire some assets and build afresh, but the emotional disruption can be huge…), combined with the greater emphasis placed on after-sales service, Gigster has had to adapt its business model accordingly.

But Gigster must be doing something right. They’ve stopped outbound marketing and prospecting, relying on in-bound leads, repeat business and client referrals. There has been a shift from a sales focus to a customer focus, complete with a dedicated customer success team.

A number of audience questions related to getting VCs interested in your idea: What do they look for? How do they assess opportunities? How far should you go in building a product before you can attract funding? What’s the best way to validate an idea? etc. Much of this is about product/market fit, building the right team, getting customer traction, and executing on your strategy (aka Product Development 101.) As part of her closing comments, Ms Waggoner noted that unlike some of the high-profile VC funds (e.g, Y-Combinator, Techstars and 500 Startups) many VCs are becoming more sector specific, because they prefer to invest in what they know and understand.

Next week: Building a Global/Local Platform with Etsy

Spaghetti in the Cloud

The combo of Cloud+Wireless+Mobile has transformed the way I work. For one thing, storing, accessing and sharing documents is now so much easier than having to send everything as bulky e-mail attachments tethered to a hard drive. However, as an independent consultant, with every new project, business or client I work with, I find I need to use different collaboration tools to be compatible with their workflow, IT systems or platform preferences. Great as all these collaborative apps are, the fact that many don’t talk to one another makes it feel like I am being sucked into a mess of virtual cables that don’t interconnect. Sort of “Spaghetti in the Cloud”.

Image sourced from Flickr

It feels like all my apps are unconnected yet tangled up in the Cloud (Image sourced from Flickr)

There is definitely a battle to dominate enterprise collaboration, with Facebook’s recent launch of Workplace to compete with the likes of Slack, the anticipated revamp of Microsoft’s Office 365 Groups when Yammer is decommissioned in early 2017, and Atlassian’s own HipChat. But aside from enterprise social media and chat, there is now competition across multiple collaboration tools. Here is a list of just a few of the productivity apps I have been exposed to across the various projects I work on:

Meetings/Chat

  • Skype for Business (formerly Lync)
  • Google Hangouts
  • Zoom
  • Cisco WebEx for iOS
  • GoToMeeting
  • Fuze
  • Join.Me
  • WhatsApp

Project Management

  • Samepage
  • Mightybell
  • Basecamp
  • Trello
  • Smartsheet

Document/File Management

  • Dropbox
  • OneDrive
  • Google Drive
  • FileApp (iOS)
  • FileManager Pro (iOS)
  • Docs To Go (iOS)

Productivity

  • Google Docs
  • Apple iWork
  • Microsoft Office 365
  • SlideShark

CRM

  • SalesForce
  • Insightly
  • Streak

And this list doesn’t include single-purpose apps like POP, Simplist and Ideament that allow some project sharing; the entire suite of creative, social media, blogging and CMS tools that organisations increasingly embrace as enterprise solutions; and the growing number of apps that support text, photo and video editing on mobile devices.

While some of these tools support content, file, document and even project sharing from within the app, a lot of functionality is native, and therefore embedded, and is not transferable. So I end up having to learn (and unlearn) the features, quirks and limitations of each one, project by project, client by client.

As I have written before, based on my experience of creating digital music (plus using and beta-testing iOS apps), an app like Audiobus set the standard for product compatibility and content integration. So much so, that Apple ended up supporting Inter-App Audio as a new standard for iOS. Since Audiobus, similar apps have emerged that allow audio and MIDI apps to run together on a single device, and to share/stream content between different mobile devices and desktop DAWs (Digital Audio Workstations): Midiflow, musicIO, AudioShare, AudioCopy, Audreio, studiomux etc.

If only enterprise software and productivity app developers would have a similar approach to product design and collaboration….

Next week: StartupVic’s Pitch Night for October