Software productization process – bring clarity to what you are offering

When I think about our passenger information solution and it’s productization, I don’t think about selling the same software to all our customers. Instead, I see productization as a process that enables us to be precise in what we are offering and communicate clearly about the features, functionalities and options included in our software solution. In our case, for example, customer-specific interfaces or other customer-specific modules are an elemental part of the software, and, instead of offering the same solution for everyone, the product can be configured and expanded according to the customer’s needs.

The process is also about recognizing our strengths, building on them, and developing them further while fixing the weaknesses that prevent us from being more successful in what we do. In this blog, I share some of my learnings on how this can be achieved.

Recognize the strengths (and building on top of them!)

Often in our work, we concentrate on challenges and how to solve them, but we shouldn’t forget about the things that are already working well. In my opinion, analysing and understanding them is where software productization should start.

For example, we at Teleste have been designing and developing software to versatile passenger information systems for quite some time now and made a lot of smart solutions over the years without actual productization. Reuse of the software has always been thought of a lot, and this is typically the way to go in software development. The foundation for productization has been built at our company long before the first SW product manager was appointed. The software modules and architecture we already have provide an excellent starting point in building on our strengths, and the product manager’s role is to analyze, direct and prioritize what is to be done in every new development project.

Maybe also you already have modules and parts of code that are reused in almost every project. List them, group them, and draw them on a diagram together with your typical project specific software. Keep re-drawing, re-grouping, and re-arranging the modules until you see a clear bigger picture. Add in the missing parts with a different colour and you have the first input for your software roadmap: one step forward is to implement these new modules!

Fix the weaknesses (but only those that limit your success!)

If you have started your software productization by recognizing your strengths, you already should have a solid base to build on. Now it is time to invest a few thoughts on the weaknesses to find out what is limiting your success. To start with, look on the most time-consuming tasks in your software projects. At this stage, productization is about finding a way to get rid of those.

On your list of weaknesses, there might be low hanging fruits but most likely there are also things that require a lot of effort to improve. You may, for example, have too much project specific code increasing the amount of design work and causing delays on your deliveries. Developing one (or more) standardized and configurable software module will help you get rid of those and improve your lead times easily. On the other hand, you may find out that you have shortcomings in project specific documentation and there are thousands of documents that are impossible to keep up to date. Such challenges might be more time-consuming to fix, but it pays off when you think about your objectives and where you wish to be in a few years’ time.

Some of your listed weaknesses can bring you some minor benefits when you get rid of them while some others could, once solved, get your company to an entirely new level. Just be sure to prioritize and think about what is possible and what could bring the biggest benefits. What is it that you need to fix as soon as possible, and which tasks can wait a bit longer? And what are the things you can keep on living with? No system is perfect and there are most likely some things that can and should be left unfixed until later. Resources are not endless so choose wisely!

Describe your solution clearly (and bring it to management level!)

Having the most brilliant configurable software system doesn’t really help, if you cannot describe it in a way that the company’s management, sales, and customers understand it. You need to be able to describe the meaning of each module or layer of your software in a simple way, unless you want to discuss them with only software experts or someone who has all the time in the world.

Your software solution may consist of dozens, hundreds, or even thousands of different modules and many of them may already be standardized. The software developers (at least those who have been working in the company for long) may even know the modules very well. However, you need to be able to present your solution in a more general level to show the management where you are with your software and in which way you are heading. If you can’t, ask yourself if there are faults in the architecture, or if you have simply missed something.

Also, your sales personnel need to know what they should be selling, and how the software benefits customers. The customers, in turn, need to understand what your solution is capable of, what are its limitations and how it can be augmented with project specific interfaces and modules. Believe it or not, a high-level description can be very useful also within software development, especially for new employees. Seeing a bigger picture first and then going to details is a natural way of learning for many of us.

Involve everyone in productization (because you can’t do it alone!)

Even the greatest product managers cannot do the entire productization process on their own. Software productization is not just about one manager saying yes or no to new feature requests but a bigger process involving several stakeholders within the company including not only software development but also management, documentation, and sales.

Remember that you can’t spend your days at the office checking continuously what the developers are doing or giving detailed instructions to everyone. You need to be able to trust that people know the direction you all are heading to and why. Be open and informative, prepare roadmaps, draw high-level architectures, and last but not the least: ask feedback and input from your colleagues! You may know the industry needs but the sales know the customer and the developers know their software.

Don’t forget about the customer (as you don’t exist without them!)

Software productization may sound like it’s done to bring savings to the company, and it only leads to solutions that are not very flexible. Contrary to this belief, it can also be done in a way that benefits both the company and the customers. This means that we are utilising proven, well-working software and processes and offering carefully designed, thoroughly tested and proven solutions with better software quality and agile updates.

It is important to remember that we wouldn’t exist without our customers. They need to be able to rely on us and if we fail in software deliveries, it means trouble for them. With more standardized offering, we can keep up with the schedules better and respond to customers’ requests and challenges more quickly. When we also are clear on what our solution offers and can document it well, that’s when the customers start really loving productization!