Building a proof of concept doesn’t have to take months. In fact, it’s quite amazing what you can achieve in a day. Here’s how we used a “build day” to figure out whether our solution to “Spreadsheet banking” was feasible and created a working build that is no longer just a concept.
For the past two years, we’ve been helping Investec build a programmable bank account for developers. Since the beginning of the beta program, the community has built some incredible use cases with the API, both for individuals and for businesses.
Then we realised the potential of opening up programmable banking to non-technical people, such as Pieter Heyns, former Head of Finance at cryptocurrency company Luno. Pieter helped us realise that entire companies are being run by non-technical people on spreadsheets, so there was a really interesting opportunity to connect Programmable Banking to spreadsheets.
That’s why we decided to have a build day to create a proof of concept that would help us show that this connection between high and low tech could solve day-to-day problems of finance managers in a way that is accessible to them. The project? Building a Google Sheets tool that will manage your bank account balance.
Together with Pieter and another member of OfferZen’s Programmable Banking community, freelance software developer Loftie Ellis, we managed to build a proof of concept for “Spreadsheet banking” over the course of half a day. Even our quick solution allows the user to get all transaction data for a bank account pulled into a spreadsheet and to automatically balance the totals on current and savings accounts. You can check out a demo of the actual POC here.
We know it can be quite daunting to prepare short, high-impact sprints like this one. That’s why we thought we’d share how we set up our build day and what we learned.
Preparing for a build day
Before we could start with the build day, we had to figure out a few things first:
Picking use cases
When preparing for the build day, it is helpful to have a problem statement and a small set of possible solutions before you start. This will help to ensure that you don’t run out of time and spend too much time discussing an open ended problem.
During our own build day, we already knew that we wanted to build out financial management features on Google Sheets and so discussions were limited to what features would be useful.
Tip: Limit the scope of your example/use case.
Picking the right experts
In order to build a solution that your end user wants and can use, make sure to include them in your build day. If you don’t let your end user guide the requirements, you will make assumptions and could end up building something that isn’t useful.
We found it essential to have Pieter Heyns in the room because he provided finance domain knowledge and end user requirements. He had specific and useful information from his experience working with startups, building fast and time spent in the financial industry.
Tip: Include the end user/ person with domain knowledge.
Also, it’s important to include developers in the team that have a technical understanding that is roughly matched. It can slow down the pace of the build if team members aren’t able to understand why each of them are performing certain actions.
For our build day, Loftie and Malan had a good understanding of each other and this ensured a good team dynamic.
Tip: Ensure that the developers can understand each other’s language.
Not everyone in the team needs to be a developer, but it’s important to make sure that everyone in the room is able to contribute. If there is one person in the group not actively contributing to the build, they become an observer, and this can negatively impact team cohesion and the dynamic in the room.
On our spreadsheet banking build day, not everyone in the room could code. However, each of us brought skills to the table and was actively involved. This included things such as imparting domain knowledge, pulling in transactions into the right format, google sheets formulas and making excel sheet templates look good for the user.
Tip: Make sure everyone will be able to contribute to the build
Ensuring useful team dynamics
Before assembling your team, it’s also important to consider the types of people who will be in the room and how they may interact because this will affect the success of your build day.
Below are a few things that we think might have helped the good dynamic we were able to foster during our build day:
Include low ego individuals: Pieter is a very low ego individual, which we found helpful because low ego individuals are typically able to focus on the moment without judgement or preconceived ideas and cooperate and work well with others.
Include high energy individuals: Aretha and Malan are both high energy individuals, which helps to build excitement around the build and keep everyone engaged. It also then balances out the quieter people in the room.
Include people that know each other from before (if you can): Pieter, Loftie and Malan have worked together before and were comfortable working with each other, which likely contributed to our success. This doesn’t mean that you can’t hold a successful build day with people that don’t know each other, but it may take a little more time to build rapport between everyone and to break the ice.
Tip: Think about the types of people you are putting together.
Appoint a facilitator
A facilitator is a necessary component of any build day and they are responsible to set the scene for the group, elicit ideas and feedback from the group as well as manage the right time to regroup during periods of building. This person will need to understand that developers require quiet time to code and therefore regroups should be strategic and try not to break the flow for the developers in the group. For our build day we found that it helped that Malan has a technical background as I had a good idea of what could be achieved in the time allowed and was able to keep everyone on track as to the bare bones minimum of what we needed to build.
Scheduling your build day
Building out a POC is no small feat, so make sure that you schedule a full day so that you have enough time. For our build day, we only had a half a day (12-6pm) and we went overtime. The things that we compromised by having a shorter build day were improving the interface and testing it out on different accounts. If we did it again, we agreed that having more time would make the day less rushed and more enjoyable.
Tip: Schedule a full day for building
Tip: Include set-up in the build day: To make sure that you hit the ground running, spend 2-3 hours before the build day to set up any accounts or install any software that is required.
Setting up a good build day environment
To set up a good build day environment, here’s a quick check-list that we’ve found quite useful:
- Set clear goals/objectives for the build day: Make sure you know what you want to achieve by the end of the day.
- Stationary: Make sure that you have a good stationary collaboration box - white board pens, stickies, prestik, paper for printing, pens, notebooks.
- Quiet environment: Ensure you have a quiet space where you won’t be distrubed and people can’t be easily distracted.
- Internet/Tech: Make sure that you have good internet access/speed and that you can print easily. Make sure you have easy access to power outlets for people’s computers.
- Slack channel: Create a slack channel 1-2 days before the build and add all the people who will be involved. This is a useful way for the team to share information before, on and after the day.
- Swag: Arrange swag packs for the whole build day team, if you can. This creates team cohesion and less of an “us” and “them” feeling.
- Snacks: Arrange snacks and have them ready on the table when they arrive. Order more than you think you might need in case you run out.
On the build day
Setting the scene before you dive into the building helps to get everyone acquainted with one another and gives everyone a clear indication of who will be doing what and what the team is trying to achieve.
Get people on Slack
When everyone gets out their laptops to start working, make sure that you get everyone onto the slack channel and start using it immediately to share resources.
Give everyone swag packs and open them together
Giving your team gifts before the build day is a good way to build trust and unite everyone before starting.
For the spreadsheet banking build day we gave Loftie and Pieter swag packs but we think it might have been better if all team members were given swag, even our team members, and if we all opened them together to generate excitement about the day. You could replace swag packs with something silly like hats or other gifts.
Start with a round of introductions
Instead of going around the table telling everyone what your job title is, rather ask them to speak to their experience and how they think they can contribute to the build. We found that this helped everyone better understand how they could work together.
Give the high level context and expectation
As the facilitator, provide clear high level context on what you want to achieve over the course of the day, and get everyone to agree to that. For the spreadsheet banking build day it was helpful to have a clear scope for our POC and we were able to get going quickly.
Facilitating flow
A build day will flow more effectively if you nominate someone to facilitate the day. A good facilitator will keep you on track and will increase your chances of successfully building out your proof of concept.
Start with the user and agree on the scope
When deciding on the solution to be built, consult with the end user on what features are necessary and helpful. Their input can help you to determine what to include.
Work visibly
Rallying everyone around the whiteboard can help to keep people engaged and feel involved. Printing out aspects of your solution can also make it tangible for people and allow them to view it from another perspective other than the screen they have stared at all day.
We found that as the build day progressed, some individuals referred to specific resources or memes, which we also printed out and stuck on the board so that we keep these things front of mind while building.
Pace out the day and take strategic breaks
As mentioned above, the facilitator should be able to pace out the day, ensuring that there is enough “focus time” to get coding done, but also ensure that the group comes back together at certain points throughout the day to share their work with one another and keep on track for the scope.
Test the solution
Be creative about how you can test your solution in real time and make it real for people. For example, it would have been a good move for us to buy coffee together to test out how that transaction pulled into our Google Sheet.
Remember to
- Order lunch to your venue: Ensure that your team doesn’t get hungry while they are building. We ordered lunch to the office using UberEats/Bolt which meant we didn’t have to worry about dietary requirements beforehand and it didn’t break the flow of the session.
- Have fun and celebrate the small wins: It’s important to not take things too seriously, enjoy yourself and celebrate all the wins you have throughout the day with high fives all round.
Post build day
Wrapping up the build day gives you the opportunity to show your team gratitude for the time and effort they put in, keeps the lines of communication open and reinforces the achievements of the day.
Send a thank you to everyone: Sending a follow up on slack or via email to thank everyone for their time is just good manners!
Post any updates on the Slack group you created: Use the slack channel that you create when prepping for your build day to post any further updates that were made to the POC, tests that we had run or any demo videos that we recorded. This keeps a line of communication open with the team.
Make a demo video or demo at a meetup: Creating a demo video of the solution and sharing it can help to generate interest in the solution. As part of our build day, I created an internal demo video of spreadsheet banking after a bit of clean up had been done to the POC. We were able to share this video with the Investec team to generate interest and help determine if this is something that businesses would want.
Get involved in the Programmable Banking Community.
If you have questions or just want to say hi to the Programmable Banking Community core team, you can pop us a mail and we will get back to you.
If you want to see more from what the community has been up to, you can:
- Browse the community’s open-source projects
- Read the dev docs
- See more demos
- Read other programmable banking related blog posts
- Get access to the community
