Let’s take a look at the best practices that Progress employs throughout engineering, product management and support: What guides our work, why are these processes important to us and how can you learn from our own internal best practices.

Hi! I’m Mandy Mowers. I’ve been working with Progress for a few years now, collaborating with external writers to create blog content that can serve our users and others in the tech industry. I haven’t had much of a chance to look inward at this company, so when an opportunity came up to talk with nine of the people responsible for our products, I jumped on it.

I’m excited to share what I learned about the practices and processes that guide Progress.

To provide a little context, I wanted to share a bit about the company’s history and structure.

Telerik was founded in 2002 in Sofia, Bulgaria. Telerik built a reputation for creating developer-facing software tools for web, mobile and desktop application development. Progress, an American software company founded in 1981, acquired Telerik in 2014.

Because “Telerik” was already synonymous with “quality developer products,” Telerik.com became the host of all our DevTools, including the Telerik .NET products and the Kendo UI JavaScript products.

The people you’ll be hearing from in this series are all working on this DevTools/Telerik/Kendo UI side of Progress, involved in creating products that serve other developers.

Let’s hear what they have to say!

One very important theme I heard was to make sure you fully learn about the problem at hand before you dive into a solution.

The first step in understanding a problem is understanding who it is that’s experiencing the problem you’re trying to solve. In our case, it’s other developers. As you’ll see, listening to these customers is a huge part of the work cycle for us.

We are in a rare position where our customers are real software developers, so the product that we create should appeal to them. So what does this mean? This means that we should be very good at understanding the ways these developers are working, what platforms are they coding in, the environments and practices that are relevant there, and how those things change with time.

We need to adapt and we need to build our components and software following the same practices, processes and tools as the developers we are trying to sell to. Otherwise the end result will likely not appeal to them. When you think about it, when we create demos and or even the way we produce code, we should use the same tooling that those developers use because otherwise we arrive with something different than what they are looking for.

What’s specific about the way we build product is, basically, we go beyond that pure software building and we focus more on a goal of helping other developers solve problems or helping them realize some huge opportunity.

We start with deeply understanding more about what they need. What their problems, needs, pains are. We translate those into a problem that we know is worth solving.

Also, we always listen to customer feedback. And then we iterate again over the cycle. Are the pains still the same? Are the needs still the same? Do we need to change something?

With our software we are striving to solve real-world problems, and with this to make our customers’ lives easier. And I can say that we are constantly in touch with our customers. We see the whole process more like a partnership between us and our customers.

We’re not the type of software company that is building some kind of software product and selling it just to sell it. We truly have a customer focus. Our code should solve customers’ pain and make their life easier. We are all developers. We love to write code. But if that piece of code doesn’t solve real problems, who will use it? Nobody.

We build software directly for our customers. We usually get a lot of feedback from our customers— they’ll tell us, “That’s not important to do right now. Right now we should focus on this and this and this.” It’s the sum of needs of all customers that we’re aiming to solve.

And I believe that’s a bit different than most software projects. You usually have some very specific goal or a few stakeholders that dictate what’s going to happen. Our customers’ voices are what we follow.

With your knowledge of your audience and their pain, then set about defining your goals for the project.

In a lot of situations, people don’t necessarily understand the real goal when you have a process. The purpose of the process is not to just be there and to be followed blindly or to be the excuse of whatever output there is. The purpose of a process to exist should be to achieve a certain outcome.

I think the biggest difference between us and other software companies will not be seen in the actual process if you compare us with others—it will be the use of the process in the first place. Everything should start by defining what is the outcome that you want to achieve. And then what are the steps that you need to take in order to achieve it, and then what is the way by which you measure the progress? And then who are the people/organization that you need to make sure that the process is being executed well? And then what is it that you can do from a software perspective that enables this process to be automated? In that order. The difference is in whether you understand the purpose of the process.

And the other thing is to have clarity of goals, to have a KPIs that measure progress, and also to have a process that ensures continuous improvement. A lot of people think that they will deploy something and it will work. The reality is that it might work, but unless you have proof, it doesn’t necessarily mean that it delivers to the needed extent from an efficiency and effectiveness perspective.

And finally, spend even more time thinking about your approach. Have a crystal-clear picture of who will be using your solution, what outcome you’re aiming for and what route you’re going to take before you write a bit of code.

Always do your homework. There is this one famous sentence, something like, “Two hours of planning can save two weeks of coding.”

So indeed, the research, the exploration, the desire to see the bigger picture and to see the real problem and how to solve it is very, very, very important. And when you accomplish your goal, it gives you such pleasure and fulfillment that I cannot express it. This is one of the things I love most in my work.

One of the things that I try to preach is that we should be thinking more about the problems than mechanically trying to solve them. Sometimes five minutes of focused thinking can save three days of work that’s put into the wrong direction. In our job, productivity is not linear.

Let’s say we start a new project. The coding shouldn’t be the first thing that we do. For example, right now we are working on a product which we believe is potentially a disruptive innovation. We’ve been working on it for four or five months, and we have written just a few lines of code. We are doing prototypes. We are doing interviews.

The one thing that I believe is very important and I instill in the team every single day is this: We shouldn’t work in silos. I think that product teams (engineers, developers, support, product managers, marketers, etc.) should, especially when they’re building new stuff, they should work as a startup, where everybody knows the context and is confident enough to understand the full context. At that point they will understand why it’s important to stop the internal desire to start coding Day Zero.

You have to understand: what is the problem, then the outcome that you want to achieve. What is the process? And then think how you can automate it. Rather than the other way around.

The other thing that might be mentioned here is the way by which we reason, and we’re big believers of principles-first thinking, meaning the process involves reasoning based on principles you hold as truths.

Great innovations come about when people don’t understand the difference between hard and impossible. If you are very fast to consider that something is impossible, how many of the things that are counter-intuitive would have never been discovered? So principles-first thinking is the other thing. We try to reason and to prove with experiments whatever we think is factual. This helps us be more open-minded and hopefully find things that are not so obvious but are potentially very valuable.

To summarize what we’ve heard today: Make sure you understand the problem you’re trying to solve before you solve it. Make sure you know who will be using your product, and talk with them. Think about the problem, strategize around it before you code a solution.

Next time, we’ll talk even more about listening to your users.