Railsware is a product studio devoted to product engineering and development. The company aims to improve business management and growth with its products like Coupler.io, Mailtrap, and Titanapps.io. In this interview with TechBullion, Yaroslav Lazor, founder and CEO of Railsware, shares insights into unique frameworks like BRIDGeS and The HEART method. He also talks about data-driven company culture and how to build successful SaaS products.
Please tell us more about yourself?
I am the founder and CEO of Railsware, a product studio. For over 16 years, we’ve been changing the way businesses are managed and growing our own products like Coupler.io, Mailtrap, and TitanApps.
It all started with my passion for tech from the age of 10. Now, I have decades of product development experience. With team experience added to it, we get the unique approaches we use at Railsware.
My key focus remains leading and reinforcing our company, which is its people and products. Still, what inspires me most is my family.
What is Railsware and what unique services do you provide?
Despite being relatively small – now we have 180 talents – we do a lot of different things. Railsware’s product studio model lets us provide several service sets.
The first is data. Our Coupler.io helps users make conscious decisions, driving insights through their data. Besides, those seeking a more advanced analysis can get a data consultancy service from us.
The second is managing the business and software development and deployment. It’s covered by TitanApps, BRIDGeS and theHeart frameworks.
TitanApps is a set of smart apps that assist companies in driving strategy, roadmap, processes, and tasks. They also help businesses allocate their people and find the best seat on the bus for them regarding context, function, and actual projects.
While BRIDGeS and theHeart are frameworks that help to capture in-depth knowledge about the upcoming work. We use them to figure out the simplest form of it to lay the first stones and the next ones for a balanced outcome of team dynamics and the product itself. Respectively, our software consultancy services use these frameworks within a client’s business context to do transformative work with the team and deliver the software.
The third one is our email delivery platform, Mailtrap. It is a powerful solution to test, send, and control your transactional and marketing emails.
So, to sum up, we run three product sets with millions of customers – Coupler.io, TitanApps, and Mailtrap. On top of that, we offer software and data consultancy services for dozens of clients.
Yet the unique side of Railsware is the team that builds the software – or, even more importantly – the approach to building the team that creates the software. Having team approaches is great, but having team members who are passionate about experimenting with those approaches and improving them is the key.
To put it into perspective, we have reviewed 50k candidates in the last three years – and hired only 150 people. It took the management about ten years to gather knowledge from the corners of the world, combine it into a cookbook, and practice it to build amazing software like Calendly, from zero to a multi-billion dollar company.
We applied this knowledge and experience to ourselves and, in the last six years, built up our product portfolio and grew 4x. We are just getting started.
Could you give us an insight into the product development market, what trends shaping the industry and the unique products from Railsware making an impact?
We can talk for hours about that, but let me focus on a few things.
Firstly, the continuous trend of data analysis and product development methodologies (as we call them “consciousness tools”) remains predominant. By that, I mean gathering and transforming data, displaying it, getting insights, making decisions, and taking action. In regards to the methodologies, it’s important to practically understand what the Agile Manifesto fathers truly meant.
Also, AI is an obvious big trend. It’s being included in all aspects above – from diving into the context together and asking what it thinks to co-product management and trend analysis.
As for Railsware, we developed apps and approaches to address both data analysis and product development trends.
BRIDGeS framework helps the team see what they deliver in an extremely deep matter so the whole team can grasp, remember, and reference back to this information.
We use our theHeart methodology to recognize the most critical aspects of development – that is, the “heart” of the future solution. It helps us bring understanding to the team, build something everyone can try, and demonstrate to potential clients as fast as possible while de-risking the implementation.
Coupler.io helps to bring and organize all your data and turn it into reports. You can do that in minutes with our dashboard templates or create your own. Also, our data consultancy services can help execute it for you: build once, run forever.
TitanApps is a growing set of portfolio and productivity tools to help you keep track of your processes. It offers checklists and templates, sets of connected issues, process assignments to let the organization operate within a well-documented structure. Soon, TitanApps will have more of our frameworks, approaches, and domain knowledge that we have mastered while helping software companies run for decades.
As one more trend, I’d highlight the Internet of Things aspect for products. A mobile device is a second screen in a process, which is not really an IoT, but as everyone has one, why not use it to offload interfaces into your mobile device? For instance, using QR codes, filling forms through mobile devices, using cell phones as car keys or wallets, etc.
What is the philosophy behind theHeart, how does it work and how does theHeart approach benefits decision-making in a company’s product development strategy?
The key idea behind theHeart is simple: every product has its “heart” – a central aspect that defines its purpose, identity, and value proposition.
This “heart” is often the most complex and risky part of a product, yet it is also the most crucial. It isn’t necessarily what users might think they need the most, like in the old saying, “I don’t need a car, I just need a faster horse.” Still, it is the one that shapes the product’s future and scalability in many aspects across the board.
In terms of practical implementation, a product team must understand the “heart” feature well. Why so? The team builds what they understand, not what you tell them. So, you align the product development strategy with the most suitable element of the product and deliver it.
While ideating the product, team members will see their version of it in their heads, even when looking at the same BRIDGeS board. There is just a lot of variety in what to start from and what to deliver first. Thus, selecting the “heart” will finally place an anchor on a specific aspect and help unroll the product’s thread from an exact spot.
In this way, theHeart also represents the right type of PoC. Regular PoCs are about building a functional “body,” while the “heart” is the centerpiece that aligns everyone together: engineers, product managers, designers, sales, marketing, and, what’s paramount, the users. It won’t be the whole product. You’ll typically get an “Aha” moment and “Now I get it” statement when demonstrating the “heart” to a person instead of showing some screenshots or explaining your vision
The challenge lies in identifying the “heart” of the product and, respectively, the product vision. But we deal with it using BRIDGeS session information. Thus, we can point fingers at things everyone has already discussed and agreed to and measure the value of what each functional team is to deliver.
To give an example, when we were developing Smart Checklist for Jira (a product from TitanApps), we started with:
- the text representing the checklist: (-) todo, (+) done, (~) in progress, and (x) for canceled todo items
- ability to edit text as a whole in a text area, omitting add, move, edit, delete, and other actions
We rendered a checklist where any action would update the text, storing this text right within the Atlassian custom text field.
This gave us a set of features out of the box without actually developing them, like search, as it’s a text field, API to create and edit issues with the checklist, as you can use Atlassian API to update the text and automation, as you just append/prepend/replace text.
So, the path to the “heart” lies through iterating the solution directions and variation and finding the best way. One more secret Railsware’s technique is called the Frankenstein Ideas. It is the phrase to let the best idea win, so we have to pick one from a set of ideas. We tend to break the better ideas aspects into pieces and combine them with other aspects of another good idea. This way, we build on top of them.
Another example of theHeart in work is Calendly. The first thing we did was make a booking page hardcoded to the founder calendar using a manually obtained API key. When we saw those availability slots render and API working well, we knew we had a product. There was, of course, a set of workflows to build and test. But it all was very obvious after we made this first theHeart anchor page: everyone had an “Aha” moment, saying, “Oh, right, that’s what we are actually building.”
How does the BRIDGeS framework help in shaping a product vision, could you elaborate?
I created BRIDGeS with Sergiy Korolov, my co-pilot at Railsware, after our inspirational and educational trip to the Valley. We understood how crucial it was to catalog and map all the information around the product’s domain. This map is like neurons in our brains – and is just 100 times easier to comprehend and remember than long texts.
Since then, the BRIDGeS framework has been helping us identify a product vision at the early stages of development and later on. It provides us with a comprehensive investigation of the problem context and building of a map of what we should be working with.
Since everyone is a part of the session to build this map, the team remembers it well. It helps to portray controversial information and ideas, set research, and see that there is nothing else to add by anyone. This certain part drives some extra sets of information that were hidden before. It brings a calm feeling that we did the best we could. Eventually, it provides a backbone for generating the most appropriate solution based on the “heart” aspect.
With the framework, you can define the Benefits, Risks, Issues, Domain knowledge, and Goals of people or organizations that suffer from an issue to move from a Problem to its Solutions.
A typical BRIDGeS session goes through four steps:
- Brainstorming
- Setting priorities
- Moving to the Solution Space
- Breaking down a Solution and working back to theHeart.
Using BRIDGeS, the initial stages of product development become more like a hackathon and take hours or days, but not weeks. Eventually, you’ll have all the stakeholders on the same page, a platform for mutual understanding and alignment, elimination of major confusion, and, of course, a clear and shared vision of the product’s “heart” and plans to bring it to life.
Who are the competitors for theHeart and what makes it unique? In what ways does adopting theHeart approach increase team involvement in product development?
Readers may notice that theHeart resembles other approaches like Agile or XP. And it’s true, to some extent.
theHeart is a product management methodology, while Agile and XP are software development methodologies. Agile and XP refer to someone who already defined what needs to be done, and they propose the way to do it. With theHeart, I aim to create a pre-context to software development methodologies.
theHeart brings all the roles together and has them work in synergy. It empowers you to think together rather than break things down into design, product management, software, support, etc.
Briefly, theHeart increases team involvement by building around a shared goal and clarity that enhances team spirit, motivation, and resilience. It reduces abstraction and keeps everyone real and practical. Nothing beats a great delivery that everyone is excited to see.
Who needs this the most and how does incorporating theHeart methodology contribute to effective product prioritization within an organization?
theHeart and BRIDGeS can actually help any function within the company execution, be it accounting, logistics, HR, sales, marketing, etc. But today, I will focus on the product teams.
When the team knows the domain space and can operate well on it, theHeart helps with big questions like “What’s to start from?”, “What’s next?” and similar.
Of course, BRIDGeS is due, and then you search for what flow to start. That quickly turns into how to start and grow it (which direction to prioritize and roll the ball). When it rolls properly and is in motion, it’s much easier for the team to be equipped with BRIDGeS session information and solution direction/variations.
If the team is new or the team didn’t show great results and dynamics earlier, theHeart will be there to build it up or focus on “who.” This process will ignite the team and build confidence to select small and easier-to-reach solutions and increase team dynamics in motion. The next iteration for such a team will already be much better and will follow the key rule of focusing on “what” and “how.”
What role does theHeart framework play in analyzing and leveraging data for better products?
When it comes to the core data of product usage, activation and selecting the proper solution direction/variation with theHeart are a must.
Here, you hope to get user feedback along the lines of “ok, it’s a bare minimum, but I feel more productive than without it.” It allows you to give the product into users’ hands quicker and thus test it much faster, giving you an early set of metrics of activation and adoption, which, undoubtedly, will be much worse than a richer version of the product. But you’ll have an accurate feeling of what the product will be like, so you can shorten the investment and the testing cycle a lot.
While doing your BRIDGeS and finding theHeart, it makes a lot of sense to log user interactions as per assumptions on the session. Once you get the data back, use it to look at your board and your solution direction and variations again and re-evaluate.
Another analysis that we urge to run is tracking team happiness: how happy and how proud a person is working on the product, measuring it before and after the BRIDGeS and theHeart sessions to see how the team dynamics changed. Team metrics are a part of the product, too, as a team is the machine that builds software.
How can a company start using the insights gained from implementing theHEART into practical improvements for products?
In the first stage, you’ve identified a product’s core feature with all the benefits, risks, and issues. You’ve ensured that the team clearly understands all the whats, whys, and hows. So it’s time to move to the second stage of theHeart and use all the practical information to select what to build from the well-discussed space.
Often, what seemed important becomes trivial and administrative product functionality. Meanwhile, certain aspects of the product get uncovered for the first time and might dictate very different product directions.
The team has a practical ability to prioritize in 3D, separating information and acting on the most critical aspects of the product at first. Before, they would select a feature that a product manager or lead engineer would deem necessary. This is truly powerful. Very often, it is a game-changer, crucial on the level of app survival.
For instance, our Smart Checklist. We built the first version in three days and delivered it to the market. We made an assumption that a text-edited checklist as a whole is a valuable way to do it, and we don’t need the regular user interface. Our assumption worked, and the product paid off. I did that inception while skiing with my family, by the way.
For Calendly, testing if API can hold real-time web requests was super crucial because if it didn’t, we would have to spend much more time on the availability engine. We also needed to know that right away as if we would first build the administrative functionality, which also depended on that decision, we would never have enough time to build the rest.
What is on your timeline at Railsware, do you have any available opportunities for investors and partnerships?
We are, in fact, working on partnerships, and each product has its own way.
TitanApps partners with marketplaces such as Atlassian and Monday.com to expand products and help solution providers deliver better value to their clients, and other apps deliver better value together.
Couper.io partners with agencies and other solution providers to help them leverage the product at the maximum capabilities and squeeze out the greatest outcome from it for themselves and their clients.
Software consultancy always partners with other agencies to cover areas they could be better.
As for timeline and investments, we are currently pushing each product forward into its long-term visions, leveraging the power Railsware accumulated throughout the years with experience, knowledge, people and money. The markets are not favorable for investments. What was 10x of ARR is often now 1x of EBIDTA.
We are, though, open to strategic investors who understand the true power of Railsware for what it is: the ability to build many products in parallel, a machine that builds machines who build the apps.
Our consultancies are also to be expanded to infinity and beyond since our approaches, principles, selection, onboarding, and allocation of the teams make an invaluable output to our clients’ issues. The more products we build ourselves, the better we become at consulting others, multiplying the experience.
At the same time, we learn from our consultancy clients. Their stories and angles differ from ours. Thus, they contain a valuable, unique set of knowledge that we then digest and reuse. This is just beautiful, no matter how you look at this.
