The supremacy of business outcomes in a low code no code world

You may know of the new low code / no code approach to developing technology solutions (good primer if not). Simply put, it offers a development platform to users that requires little to no coding capabilities to build applications. There are benefits to this but also challenges which is why its important to consider the adage, just because you can, doesn’t mean you should. In this post, I consider the importance of business outcomes, choosing the right platform, governance and pitching your solution.

If you read the primer I linked to above you will discover the Citizen Development moniker, which relates to the no code aspect. I have also written about this here: For citizen development to work address innovation culture first. It’s true that before any encouragement of this type of activity takes place you do need to address your innovation culture first. For this post, let us assume that has been done.

In a low / no code world, every problem risks becoming a nail. When you have a tool that can do lots of things, you might be inclined to start doing lots of things, even when there is no merit in doing them. This concept is referred to as the Law of the Instrument. This lends credence to the adage “just because you can, doesn’t mean you should”.

And this is where business outcomes come in. I have written about that before, for past reference – see the many posts here.

Business outcomes

In the work I do in customer success, this relates to what a business experiences as a result of using technology in a certain way, in terms of impact to its performance. This is also an excellent filter and measure for deciding on any application that will be used by the business.

Sometimes however, there is merit in starting with obvious processes or needs that can be met with an app and not thinking too hard about it. Especially if you are in a small organisation and an inventory of what is being used is simple. Where you know of an obvious need that is not being fulfilled which can easily be developed in a low code / no code way, just do it I say. Great examples are expenses management, holiday bookings, etc.

In larger organisations where things can easily proliferate and go beyond basic applications, I think you need to think a little more carefully about these things. Business outcomes will be an excellent filter for you to use and can be considered in any of the three main considerations I have listed below, once you have decided to get a little more programmatic about things:

The platform

At Microsoft where I work (disclosure), there are several ways to utilise this platform approach. Power Platform is the obvious one. Microsoft Teams a little less so, if you don’t work at Microsoft perhaps. But read this documentation for developers and you will see that it is very much intended as a platform. Then there is Azure as a platform for application development as well as Dynamics 365.

I’m not trying to sell Microsoft’s various application development platforms, I just know it best because I work there. I did want to show the breadth of possibilities and how strongly the platform approach is being positioned, especially the Power Platform for Citizen Developers. And I’ve also written a post about how you can go about Deciding on business outcomes with Microsoft three clouds which touches nicely on this topic too.

But there are many others. Amazon just recently entry the fray with Honeycode in a show of the significance it places on this growing trend. Salesforce was one of the first. They have a great article here on selecting frameworks: 5 Key Criteria for Selecting Low Code Application Development Frameworks.

The fundamental point is to select wisely and there will be no shortage of help on how to do that well.

The governance

There are at least two aspects two consider with this point:

• Having a governance framework and a way to manage oversight into what is being built, deployed and used is critical. Microsoft advocates for this heavily. And there is an admin centre that allows for such highly granular oversight. This covers the technical side of things.
• On the business side, there should also be a governance framework in place. This should cover things like:
  • A way to capture requests for the development of new applications from the business. This is likely be controlled by IT but should at least partly be governed by business folk. Keep it simple. This can also check for duplicate requests or whether something like it already exists.
  • A stage gating process through which requests must pass and succeed at every stage to progress further. This should also not be overly cumbersome to stifle innovation but it should be rigorous enough. A key thing to measure for is what business outcome is expected and how will it be measured.
  • At some point you could include a pitching process, especially if there is a call for ideas in a Hackathon for instance. Even if not a formal pitch, elements of pitching should be considered, either at each stage gate or all at once.

The pitch

This is especially required in my view, the more broad or impactful the business outcome is expected to be. You are not going to be pitching every simple little app.

Startup innovation and the pitch deck that often accompany startup pitches to VC’s, is the standard bearer for this kind of thing.

You don’t have to go far to find examples of great pitch decks that managed to achieve their intent – in these examples, funding.

Is pitching inside an organisation different? According to Staffbase, a little. I would agree there is little difference.

Using this outline from Rocketspace of the 8 components of a winning startup pitch deck, which is as good as any you will find on the interwebs, I have added some notes of where I think it might differ inside an organisation.

• Problem. This holds in the enterprise, absolutely. It could also be needs, or even Jobs to be Done (renowned innovation thinker Clayton Christensen’s believed that “people buy products to get a “job” done”) – just replace buy with use in the enterprise.
• Vision. The one soft side of things allowed – this is what will inspire.
• Unique Value Proposition. I would make this business outcomes.
• Team. Less important in the enterprise unless its a very large scale project.
• Milestones. Definitely applies in the enterprise
• Business Model. This could be replaced by business outcomes too.
• Competition. What is not so relevant in the enterprise is the kind of competition a startup would get in the marketplace. But when it comes to competition with other apps and for the attention of busy and overwhelmed business users, then it absolutely holds.
• Ask. Probably the most important and most neglected. Finish strong with this in terms of what you need and are asking for and who’s support you need to make it work (think executives).

If the pitch does go to a presentation in some form, then it goes way beyond the pitch deck, to the presenter too, as this HBR article describes: How to pitch a brilliant idea.