1. What led you to ProdPerfect?
After college, I decided to work in web development. I went to a boot camp where I met ProdPerfect Co-founders Dan Widing and Erik Fogg. They were exchanging mentorship for some resources when ProdPerfect was still in its early stages. They said: We’ll keep you in mind for our company. Lo and behold, ProdPerfect was growing so fast that they called me basically 8 months later. The offer was way too good to pass up: small company, growing fast. I had a lot of autonomy and got to work with people I knew and respected.
I’ve now been working here for as long as I was working at my old job. I feel so much less burnout and so much more enthusiasm about where I am than I did being a very small cog in an engineering department of 1,500. And that’s very fulfilling.
2. What sets ProdPerfect apart from other places you’ve worked?
It comes down to the people. There is definitely a coherent ProdPerfect team culture. Everyone at ProdPerfect is the sort of person I want to spend 8 hours a day with. They’re ambitious and excited about what we do, but also grounded and down-to-earth. There are no caricatures. You don’t get the stereotypes of introverted, overly opinionated engineers or hyper-aggressive salespeople. They’re just real people. And God, is that refreshing to work with.
Everyone is super dynamic and responsive. I’ve seen situations where unwavering preferences about engineering design make people set in their ways. You just don’t see that here. I’ve seen departments complain to one another in a most productive way. In other situations, you can just sense the egos and the tension of “I need something from you.” I’d be shocked if anyone here were anything but super willing and eager to help in any way they can. Of course, there’s push-back and there is constructive debate and dialogue. But there’s never: “We’re going to do our thing our way.” People are intellectually modest enough to lean on others. Nobody is so entrenched in their biases that they can’t see the greater picture.
3. Can you paint for me a picture of what life is like in your role?
As delivery engineers, we produce the final, customer-specific deliverable. We take information that comes from data engineering and use it with tool sets produced by other teams to produce a test suite. This is a big chunk of code which tells the machine to simulate the experience of a user clicking through a site. And we set that code to run on a timely schedule. In theory, if the customer sets it up, it also runs every time their engineers want to make a change to their website before it goes live. We encourage customers to use our product as a final check mark that confirms they’re set with every change they make.
I divide my job into things that are predictable and things that aren’t. Predictable things are part of the regular cycle of spinning up a customer: collecting data, running the analysis, and generating test cases. Once test cases are generated, I oversee the people who write tests: I review their code and answer questions. I also communicate with the customer about the state of the test suite and things we need clarification on. Then we hand it off. All of this usually happens within six weeks. What’s not predictable is we’re constantly monitoring when our tests fail and figuring out why. If it’s a bug, we forward the information to the customer. If it’s a change in the website or something goes wrong with tests, we update the tests. New features, new tools, and one-off things also comes up all the time, so I budget some time in for the unpredictable every day.
4. What are some elements of a typical interaction with customers?
With customers, I get brought in as early as the product demo stage. We serve a technical support role alongside salespeople as they walk customers through our product. Being close to the production of the test suites and understanding the data engineering team’s analysis, our team is in a good position to clarify and respond to more specific technical questions. We’re also brought onboard to understand the peculiarities of customer applications to determine if ProdPerfect will be a useful tool for them. Once the contract is signed, we are part of the process all the way through: we get all the information we need in order to access their staging environments to test against them. We communicate with them about the progress of gathering data and the creation of their test suite over Slack channels.
5. What intrigues you about delivery engineering at ProdPerfect?
Some engineering departments can feel peripheral and maybe foundational, but not central. We feel central. The organization has a lot of moving parts, but ours is the one that most closely looks like what we describe when we talk about our products and services. We produce the deliverable. Being responsible for the final deliverable has its own privileges and challenges. We are relying on and therefore learning about every other department. This means we have to have a shallow amount of knowledge about everything that’s going on around us. Extracting what others are producing as it’s relevant to us is sometimes the most efficient way to get the heart of what they’re doing. That’s a lot of my day. It’s fun to be able to learn a little bit about all parts of the organization. There really isn’t anything we don’t touch or that doesn’t touch us.
6. How do you explain to people the value of ProdPerfect?
We collect information about how people are using your website. And we recommend tests to be created that specifically verify that the parts of the website most people see are working. If the log-in page is seen by 80% of users that visit your site, you want to make sure that your log-in page is working. I often get asked how ProdPerfect is able to support a bunch of different organizations in quality assurance testing. The answer is because we’re making test suites that aren’t trying to support everything. We’re identifying the most important stuff.
We’re not trying to be the be-all and end-all; we’re trying to provide a very targeted kind of value. It’s not worth your time to put the same amount of effort into resolving a niche edge case versus things that are more visible or that iterate on your product. We explicitly don’t do that. Everything is a trade-off of time. Choosing this trade-off gives us the ability to maintain the test suite in a more robust and dynamic way, which is a really unique principle that ProdPerfect operates under.
7. In your own words, how would you differentiate ProdPerfect from competitors?
The major thing that distinguishes us is data collection. Anyone can give a contractor access to their application and tell them: “Go through and make a bunch of automated tests based on whatever you think should be tested.” It’s another thing entirely to give people the power to say: “We’ve got the top 70% of our workflows covered.” People appreciate that knowledge and sense of security. They appreciate that we integrate with their development workflows in a way that can mean that they never push a bug to production. We have customers that testify to that.
We are also very focused on the kinds of customers we are working with right now. We’re not doing a lot of mobile or native desktop testing; we’re focused on web applications. So our customers are usually Software as a service (SaaS) companies—usually smaller, start-upy kinds of companies that are iterating quickly and are more liable to make mistakes, but will also suffer more because of mistakes. In this sense the customer we’ve started to target in the space we occupy is getting more specific as we mature as a company.