Amazon was my first full-time employer. I arrived straight out of university, with one goal in mind - to become a great Software Developer and use this skill to "make history".
As a developer, I was taught to think about algorithms, code optimisation, clean code, etc. But somehow that didn’t seem enough to push some of my projects forward. One great thing about Amazon is that the customer always comes first and that is what dictates whether a project gets in the development pipeline or not.
So what do you do when your idea of a impactful project does not match the customer’s view on it?
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 the two points of view.
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.
My first lesson was to take time and understand the customer’s needs before making any decisions about software design and implementation.
This is actually 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 listen, keep an open mind about everything.
After listening and getting some rough requirements, the next lesson was to ensure a fast customer feedback loop.
In the same way that functional and integration tests are run on each project deployment, customer feedback on a regular basis is essential. The more often you do it, the more confident you are in your project’s stability.
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. In time, the development team’s confidence in their own development process grows and feature development becomes faster and easier.
Let’s 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, then our product and partnership can only grow.
At the end of the day, it’s trial and error. I try to I keep in mind these lessons whenever I start on a new project. I don’t get it right all the time but hey, Rome wasn’t built in a day.
And here I am working in a startup. The customer feedback loop is as short as it gets and the stakes are higher.
So how are we, at PassFort, working backwards from the customer?
One of the projects I’ve been involved with in my first months here was building our risk engine.
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 need to run an enhanced verification or not. (note: enhanced verification may take longer and cost more to run for our client)
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 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 want. So the whole team, business and engineers, gathered together and did some brainstorming based on the customer’s needs. What came out of that meeting, was a simple, rule based risk engine - fast to implement, easy to understand, that would get the job done.
As a startup, we always need to make sure that our efforts are directed in the best direction possible. So keeping a short feedback loop was essential.
The first iteration consisted of implementing 2-3 data points. It was more a proof of concept than a finished product, but it was enough to buy interest from our customers and thus make it possible for us to continue developing it.
Looking back, I can actually see how we followed the ‘working backwards from the customer’ principles, and we did it as a team.
The turning point, I believe, was the team brainstorming session, when we all got aligned behind the same goal. From then on, it was all a natural sequence of events.
When you’re building software for a customer, the importance of customer feedback can't be emphasized too much.
Amazon does this by making customer obsession one of their core values, if not the most important one.
I think that is why it stuck with me - and because it actually made me more efficient as a developer.
At the moment, PassFort works at a much smaller scale, but the same principle applies. Here, similar to Amazon, a great customer experience is essential. And these learnings are actually even easier to implement than in a larger scale company.
Developers, business, product - we are all one single team. Feedback from the customers doesn’t have to go through too many loops to be fed into the product, which is something that we will need to keep in mind as we grow. The good news is that it will have been part of our culture from the beginning.
Oh, and if you’re wondering what the plans are for our risk engine - we’re going to make it grow and make it smarter, one step at a time. I can’t really say I know what the steps will be now, but what I can be sure about is that it will be customer driven.
I’m imagining we’ll continue by adding more data points, more rules, then make it more configurable for our developer customers. And soon after, we should have enough customers and enough data to provide good data driven alternatives to manual rules.
We’ll make sure to add a blog post about that!