PassFort's engineering team work backwards to solve problems

Andreea Gherman, Technical Lead at PassFort, shares her (and our) principles for software development

Amazon was my first full-time employer. I arrived fresh from university with one goal in mind - become a great Software Developer and use this to make history.

As a developer, I was taught to think about algorithms, code optimisation, clean code, etc. Still, somehow it didn’t seem enough to push all my projects forward. Think what you will about Amazon, but one thing they have nailed is the customer always comes first. That dictates whether a project gets into their development pipeline or not.

What do you do if your idea of an impactful project doesn't match the customer’s?

Above all, I wanted my work to be useful, but in the end that meant taking a step back and figuring out how to reconcile two points of view - mine and the customers'.

Here are a few lessons I learned along a way. I hope you’ll find them useful, either as a reminder or as something new to think about in your sphere of software development.

My first lesson was to take time and fully understand the customer’s needs before making any decisions about software design and implementation.

This is quite common practice in software engineering, but the key ingredient I was missing was to start with a clean slate. I had to leave all my previous ideas behind and really listen. I needed to keep an open mind about everything.

After listening, noting and getting some rough requirements, the next lesson was to create a fast customer feedback loop.

In the same way functional and integration tests are run on each project deployment, customer feedback on a regular basis is essential to any project. The more often you do it, the more confident you can be in its ultimate stability.

Continuous delivery

Let’s say we are working on a large project and we’ve written a good amount of tests to check that the product is behaving as intended.

It may not be an easy task to write them in a robust and maintainable way, but when the number of bugs that slip into production gets smaller and smaller, it’s worth it.

Over time, the development team’s confidence in their own development process grows and feature development becomes faster and easier.

Replace the word 'tests' with 'customer feedback' and assume that we run the product through customer feedback every time we make a release.

It may take time to get into a routine, and it may even be uncomfortable at first, but the more we get to know the customer’s needs the closer we get to delivering the perfect product.

If we have a relationship where we, as developers, are able to count on customer feedback and customers trust us to action their feedback, our product and partnership can only grow.

At the end of the day, it’s a process of controlled trial and error. I try to I keep in mind the lessons learned from my days at Amazon whenever I start a new project now at PassFort.

I won’t get it right all the time, but Rome wasn’t built in a day. I learn fast what fails and build better from a sure foundation.

How does PassFort work backwards from the customer?

Now I'm here at PassFort and working in a startup. The customer feedback loop is as short as it gets and the stakes are higher.

One of the projects I was involved with in my first months was building our risk engine. This is now the central engine that everything else in the platform is built around.

How did this approach to development emerge? For a customer, of course.

To make a long story short, one of our customers asked us if we could add a risk engine to their customer onboarding policy. The idea was to classify a customer as high, medium or low risk, based on several data points.

This classification would allow our client to decide whether they could onboard this customer and also, whether they needed to run an enhanced verification or not. The enhanced verification may take longer and cost more for our client. Therefore it's in their interest to complete enhanced verification only when appropriate.

This project had huge potential both for the business and as a pure piece of software engineering: choosing what data points we are going to implement, building smart models on top of them etc. Just imagine the data analysis algorithms we can run!

But, there was a delivery date attached to it, and a great deal of research that our customer had already done to know which data points they wanted. The whole team - business and engineers - assembled to thrash out ideas based on what this customer needed and wanted.

What came out of the meeting was a simple, rules-based risk engine - fast to implement, easy to understand, and one that would get the job done (extremely well) for our client and for the customers they were onboarding.

As a startup, we always need to make sure our resources and efforts are directed in the best way possible. Keeping a short feedback loop was and remains essential to us.

The first iteration of the risk engine consisted of implementing 2 to 3 data points. This acted more as a proof of concept than a finished product. It was enough to get buy-in from our customers and that made it possible for us to continue developing it.

Looking back, I see clearly how we followed the principle of ‘work backwards from the customer’. We did and still do this as a team, and it's something I know I always will.

The turning point was a team brainstorming session. We got aligned behind the same goal. From then on, it was a natural sequence of events.

Building great software, the importance of customer feedback can't be overemphasised

Amazon has made 'customer obsession' one of its core values and it's undoubtedly the most important one. I think that's why it stuck with me. It made me more efficient as a developer.

PassFort obviously operates at a much smaller scale than Amazon, but the same principle applies. Here, as at Amazon, a great customer experience is essential to our clients and their customers. And customer obsession is easier to implement in a smaller company.

Developers, business, product - we are all one team. Feedback from our customers doesn’t go through hundreds of loops to be fed into the platform. This is also something, by the way, which we are obsessed with as we grow. The good news is, it's part of us, in our culture from the beginning; it is coded in.

Oh, and if you’re wondering where next for our product...

The developers at PassFort have continued to significantly grow our risk engine and make it smarter with each step. It is now one of our most important building blocks and, with the help of our customers, we keep finding ways of using the risk engine to make the platform more configurable, and add more data driven alternatives to manual rules.

What next?

We'll let our customers decide first and work back from there.

Get in touch

If you would like to talk to us about your requirements for automating risk and compliance processes, please get in touch, we would love to hear from you.