Can humble business people like you or I create their own software applications to put a dent in the world?
So you’re sitting there in a meeting. Bam! You get hit with a great idea to make life easier… for you, your colleagues — or any particular group of people. If you had a software developer’s skillset, you would be a gazillionaire… right?
Solve your own problems — and others too.
Let’s introduce some good news. You do have a software developer’s skillset… you don’t know it yet, that’s all. We live in a time where it is easier to develop software; the production of different types of software is increasingly commoditised.
Business leaders, solopreneurs and project professionals alike are well-positioned to create software—Nope — no large software teams, and no outsourcing to who-knows-where. Like anything worthwhile, this achievement may be a … little… outside of your comfort zone. Nonetheless, it’s possible!
No code (and low code) software can help you develop your ideas: even a working prototype or minimum viable product (MVP). With an MVP, you are likely to attract funding (if needed).
The rise of No Code
Know how to work a Google Sheet? Excellent. Want to create an app for Android or iPhone using data housed in your Google Sheet? Check out Glide. Their training videos are brief and polished.
This blew my socks off. How cool would it be to develop an MVP for a client with minimal work? Yes, your users can enter data — it’s not just read-only. You can link back-end tables, too, using their (relatively new) database. Glide looks like a viable tool for what you need to do.
My thirteen-year-old son knows better. He says: “Dad, these tools are for business people with no idea about software development. Once your idea gets serious, you need to hire developers.”
Maybe so, but could low or no-code solutions get you to a stage where you have a working prototype? As Sheryl Sandberg says, “Done is better than perfect.” Progress over perfection to me is just as good. Enjoy the salty, wonderful taste of impending victory with viable steps towards your solution — even if it isn’t perfect.
Bubble.io is another contender — with a steeper learning curve, yet with many templates. You can buy then modify these templates, making a Frankenstein’s monster of an app! Need a series of tables for linking together customer relationships? You can buy templates to capture and funnel customer information.
Tinkering around in Airtable is another way to go. You can create an excellent MVP using Airtable, as it functions as a database (and so many other tools). You can use Airtable’s functionality as your “back-end” database, then put a prettier front-face on. Airtable integrates with Bubble.io. Integrations like this can help you get the best of both tools’ functionality. Other front-end tools help you manage new users to your Airtable “system”.
While low or no-code tools may be limited in functionality, you can find useful functions like Gantt charts. With some extra skills, you may achieve drag ’n’ drop functionality or other ways to make life easier for users.
So, where do you start?
Your solution awaits. But where to begin? Your enthusiasm for your idea may be strong today. Yet, any effort to create something worthwhile and durable is a marathon. You may suffer through pain barriers to create your solution. You learn a great deal about who you are during the creation process. Trust me, it’s worth it.
Once the price is paid, the quality remains. This is a quote I heard once.
Yet out of breath, you stumble across the finish line. Your application is online, and it works, despite the small bugs you see in it (despite best efforts). Then you look up, still panting: you have another two to three years ahead.
“Start promoting three years before the book comes out”
- Seth Godin
It would help if you still promote your solution to the world. So how do you do this? This article will help you.
Pains and gains
You could start with a focus on the pain your solution solves. You may already have this pain point in mind.
Sometimes users may not realise they have a pain point. A great case in point for me is when I started using Workflowy. No, this isn’t a paid endorsement. I came across Workflowy one day as I was trying to organise my thoughts and heard about using outlining tools. Outliners looked a bit techy — with a markup language. Workflowy’s interface looked inviting and easy to use. It had drag ’n’ drop functionality, and it could manage the weird and wonderful maze of my thoughts.
Most importantly, it was free. I started using Workflowy, and each morning I got an email with my previous day’s updates. Looking at my updates got me thinking about my Workflowy notes, and I would open them again. I could use Workflowy on my mobile or computer, and my random thoughts ended up in Workflowy.
I was a goner—a hooked user. When I started writing my book, I relied heavily on Workflowy. After 250 entries, Workflowy told me I had to upgrade. Yep, I upgraded in a heartbeat. After all, I had used it so much it became part of my personal “tech stack”. My productivity eco-system, if you will!
See the animated .gif file in this article? That’s Workflowy! See how you can drag and drop points around, expand and collapse points — even show images? Bloody brilliant. For a propeller-head like me, this simplicity is genius.
So why go on about Workflowy? Well, it snuck up on me. It was easy to use, I started to use it habitually, and before I knew it, I was a goner. If you’re investing sweat equity and pushing through pain barriers on any creation, make it a good one. Please make it in a subtle way so the need to use your solution sneaks up on hapless users like me. Make it so users open your application every day.
Not just a pretty face
How do you design a solution your users are compelled to regularly use? The daily “update” email from Workflowy kinda hooked me. But the simple drag ’n’ drop interface helped me arrange my mind's chaos into a neat outline.
Low or no-code solutions may mean that you have to phone a friend on a sexier interface. There’s nothing wrong with this. You can also develop your own wireframes. Wireframes are great for helping you articulate the look and feel of your application, and I used Balsamiq, my go-to wireframe solution.
Funnily enough, Balsamiq’s capabilities may extend to your work as a project or change professional. Are you in the early stages of your project and don’t have a tangible future state to show people? Then whack together a wireframe! Even having something is better than having to rely on people’s imagination.
Your user interface should extend to reports. Can your coding solution help you with viable reporting options? While Google Charts may relate to websites, it is worth checking out these Google Chart options. For example, if you need a decent Gantt chart, here’s Google’s contribution.
What does a Minimum Viable Product (MVP) look like to you?
Discipline yourself not to go nuts with functionality. What at a minimum can you provide to solve your user’s pain?
I KEEP six honest serving-men (They taught me all I knew); Their names are What and Why and When And How and Where and Who.
- Rudyard Kipling, The Elephant’s Child
Start with your six honest serving men. This structure for thinking covers the basics related to solving a user’s pain: what, why, when, and how.
Who is your user, what does the user want to do, how will they accomplish this, and how should your solution respond?
Write down several major use cases for your user. Do not fret about how you will achieve this (via no or low-code solutions) yet.
Another way of approaching user pain points is via empathy mapping. This is an example empathy map from my book The Change Manager’s Companion.
This simple map starts with where the user currently is and where they would like to be. You can use this map to explore their pains (and gains). The lens of using their thoughts, feelings and behaviours is interesting. Moreover, this lens can be useful for use case construction.
Relationships make the world go ‘round: What does your data layer look like?
Does the term “entity-relationship diagram” (ERD) freak you out? Here’s an example of one below. This example is for a potential solution for change managers, and companies like ChangePlan, ChangeFirst or The Change Compass work in this space.
These companies provide change management solutions addressing two major pain points:
- As an organisation, we don’t have a single view of change;
- As a change practitioner, I want a solution to help me get my job done with greater ease and effectiveness.
Some companies cater for both pain points. Depending on your job background and the context for your solution, what are the major pain points your solution might address?
As you can see, an ERD shows the underlying tables of your solution. The ERD illustrates how these tables link together. What if you look at relationships at a higher level to begin with? Here is a business-friendly example of interconnected relationships:
Each table needs a primary key, and this key helps us avoid duplications and chaos amongst our datasets. Referential integrity is a term describing an orderly table linkage (and consistent, accurate data).
So what next? When can I be the next [insert software guru here]?
Hopefully, low or no-code solutions readily available (and this article) changes your assumptions. What assumptions? That you need a team of technically-skilled boffins to construct a solution.
So what next? I have intimated that the layperson's software development process is more straightforward, but it still isn’t easy.
1. Think through your use cases for this solution;
2. Sleep on it. Are you prepared for a double-marathon ahead? One marathon for the build and test, the next for marketing, promotion and software road mapping.
3. Draft your data layer. It can be on a piece of paper. Here’s an example scribble that I call an entity-relationship diagram. See? It doesn’t have to be neat, orderly or blow anyone’s socks off. It’s for you to help you get your head around a complex relationship. Your users won’t see this complex relationship; it is the foundation of your house.
4. Start tinkering with various no-code solutions. Tinkering means exactly that — have a play around with various solutions.
5. With tinkering, you start to learn about the strengths and weaknesses of each solution. How they support your solution’s front-face and back-end. The former includes users registration and payment, plus a reporting suite. The back-end includes how easy it is for users to update your solution and how readily these tables update. There’s far more to it than this, but this is a start.
6. Over weeks and months, step away from your tinkering. Start to build parts of your solution. Remember, how do you get users hooked on your solution? Gamifying the experience? Like Workflow’s email the following day, delight the user by reflecting their progress?
7. Move towards your MVP. Enlist friends and trusted advisors to conduct user acceptance testing for you. Don’t be overly prescriptive in what they should or should not test — let them play with the MVP.
8. Bug fixing — it’s your life now.
9. Prepare to publish. Break down at the finish line of marathon # 1.
10. Swig some water, take a breath and limber up for marathon # 2: promoting your solution.
I hope this article gently challenged your assumptions about developing your own software. You don’t have to have the specialist skills of developers, and you may have to wade waist-deep into the waters of development — just enough to build your confidence. You also gain the confidence and satisfaction of a complete end-to-end system build.
Whether the money flows is up to the strength and timing of your idea and your marketing efforts. If you are now considering taking up this challenge, good luck and well done.
Our book — The Change Manager’s Companion — is available now. You can also check out our online course on Change Management.