{"id":17554,"date":"2024-09-24T10:37:05","date_gmt":"2024-09-24T07:37:05","guid":{"rendered":"https:\/\/railsware.com\/blog\/?p=17554"},"modified":"2024-09-24T10:37:06","modified_gmt":"2024-09-24T07:37:06","slug":"from-idea-to-impact-inside-railswares-journey-to-product-studio-success","status":"publish","type":"post","link":"https:\/\/railsware.com\/blog\/from-idea-to-impact-inside-railswares-journey-to-product-studio-success\/","title":{"rendered":"From Idea to Impact: Inside Railsware’s Journey to Product Studio Success"},"content":{"rendered":"\n

Over the past 17 years, Railsware has grown from a team of four to over 200 craftspeople. Guided by our values of high-quality craftsmanship, we ditched the initial outsourcing model early to build a product studio instead.<\/p>\n\n\n\n

\"\"<\/figure>\n\n\n\n

And now Railswarians build damn good products both in our offline workspaces in Krakow, Kyiv, and a recently opened location in Warsaw, and online \u2014 from every corner of the world. This commitment has earned us a place among the top 20 product studios in Ukraine, as recognized<\/a> in 2024 by Forbes, or in the list<\/a> of top 12 software houses in Poland.<\/p>\n\n\n\n

Our co-founders, CEO Yaroslav Lazor and Managing Partner Sergiy Korolov, are passionate about sharing their experience and insights. So, no wonder Romeo Mann, founder of MAN Digital, and the host of the The RevOps & ABM Alignment Podcast, was happy to invite them to his show. During the sessions, they delved into the details of building a product studio, and explored the challenges faced and the growth strategies employed.<\/p>\n\n\n\n

So, whether you’re a member of a startup team or a seasoned engineer, read on to the shortened transcription to discover how Railsware creates damn good products in the ever-changing tech industry landscape. 
<\/p>\n\n\n\n

Another Hollywood success story? Not necessarily<\/h2>\n\n\n\n
\"\"<\/figure>\n\n\n\n

Romeo: Who is Railsware?<\/strong><\/p>\n\n\n\n

Yaroslav<\/em>: (smiling<\/em>) Railsware is this animal we keep in our secret lab and take energy from it. But other than that, Railsware is a company. We call ourselves a product studio because we’re a studio that produces products. We build a lot of them for our own needs and our own SaaS products. We build a lot of products for our clients as well\u2014a lot of successful ones\u2014that makes us a successful product studio. Sergiy, we should call ourselves a successful product studio.<\/p>\n\n\n\n

Sergiy<\/em>: Many companies in Eastern Europe try to find the silver bullet for how to execute. Yet, we know just a few examples of companies that have succeeded. Railsware is one of those.<\/p>\n\n\n\n

Romeo: You guys are the only software house I know that is as obsessed with products as you are. Did you always have the clarity you needed to focus on the product? Could you go back a little bit in history on how Railsware started?<\/strong><\/p>\n\n\n\n

Yaroslav:<\/em> The history of RW<\/a> starts with a lot of confusion in the early days. We can cut that out and make a typical Hollywood success story where you glue the awesome pieces together.\u00a0<\/p>\n\n\n\n

Over the years, as we were able to execute properly on various elements of the company, we aimed to maintain high quality in all aspects\u2014execution, organization, operations, and management. We always wanted to be conscious of what was happening, not just reach a certain point by luck or somehow roll to the finish line. We want to be glorious at the finish line and look great at the same time.<\/p>\n\n\n\n

During the early days of Railsware, Sergiy and I combined our interest and urge for great products and pushed further. It all started with consultancy\u2014we were helping other companies build their products. We had some decent work to focus on from the early days, which helped us grow. Then, we became serious about our own products. <\/p>\n\n\n\n

When I say serious, I mean it’s super hard to build a product, deliver it, and understand how to tweak it to achieve product-market fit. To even understand what product-market fit is, you need to run all the functions that make a product successful: sales, marketing, product management, engineering, frontend engineering (which is sometimes slightly different, although, in our company, we opt for full stack), support, and operational functions like procurement, office management, accounting, and legal. Hopefully, I’m not forgetting anything. <\/p>\n\n\n\n

Romeo: Wasn\u2019t it tempting to just go into the typical outsourcing model?<\/strong><\/p>\n\n\n\n

\"\"<\/figure>\n\n\n\n

Sergiy<\/em>: In the beginning, it was more like outsourcing because we mostly focused on engineering, with a bit of design. There was no product management as a discipline.\u00a0<\/p>\n\n\n\n

But around 2010-2011, we were at a crossroads. We were thinking, \u201cShould we grow in numbers and just provide the same type of service?\u201d or \u201cShould we focus on higher quality and become more like a premium software shop where we solve problems for our clients?\u201d <\/p>\n\n\n\n

We chose the second path to become a trusted partner for those who have a problem and may not understand how to solve it technically or product-wise. Meanwhile, we started to learn from our colleagues in the United States\u2014companies like Pivotal Labs. We met with them and learned their approaches to building products. We adopted the model of premium consultancy and product building to our reality and started to achieve successful deliveries one after another.<\/p>\n\n\n\n

Romeo: How does your method differ from having developers on the bench, and what makes it more effective?<\/strong><\/p>\n\n\n\n

Yaroslav<\/em>: Two things. We had an advisor who was once the CEO of Pivotal, and he said that running a consultancy requires high performance and diligence. However, building and running a product demands a spark of genius to see reality correctly. This spark of genius cannot be created by simply taking developers from the bench and telling them to “spark the genius.” It just doesn’t work that way.\u00a0<\/p>\n\n\n\n

As the book “Good to Great” emphasizes, your best people should be focused on your biggest opportunities, not your biggest problems. You need your top talent working on your product to ignite that spark of genius. Relying on a bench of developers to figure things out is not a viable strategy.<\/p>\n\n\n\n

Sergiy<\/em>: Besides, it was never our story to initiate a product because we had a bench. Our motivation was to productize the approaches and tools we had inside the company. Every product appeared from solving our own problems as a company. Then we learned that other companies might have the same problems. And if we make our solutions publicly available and unify the workflows, other companies could potentially use them\u2014and they actually do. That’s why we have millions of users of our products.<\/p>\n\n\n\n

Turning problems into products<\/h2>\n\n\n\n

Romeo: Can you walk us through the process of building the first product? Did you discover the problem by chance or through a planned approach? <\/strong><\/p>\n\n\n\n

Yaroslav<\/em>: So basically, we did a ton of products and then released some of them. I wish we had released all of them and trusted in our ability to execute those products. But then, we felt like a Ukrainian underdog. It’s so cool to be in the U.S. and deliver products, and you’re sure they’ll work, but why would it work for us? Eventually, the underdog mentality faded away, and we were able to execute this product right.<\/p>\n\n\n\n

The first product we launched was Mailtrap<\/a>. We had a problem with sending emails from a local machine or staging server that could trigger sending real emails to real clients\u2014fake emails, in this context. For example, you might be on a staging computer with a copied production database and accidentally send emails like “Your account was deleted” to actual users. They would freak out, reply, and we would have to explain it was a staging event. Or we would test email campaigns and accidentally send them to 200,000 people.\u00a0<\/p>\n\n\n\n

We experienced these problems firsthand and realized that solving them would be a great idea. Someone in the company had spare time, built the first version, and then we rolled it out. The community started using it, and five years later, we made it paid. But that\u2019s not the ideal way to launch products. Launching a product should be much more focused and lean. You need the right people to do it. Our third product was the one we really focused on launching.<\/p>\n\n\n\n

Sergiy<\/em>: As Yaroslav mentioned, our third product, TitanApps<\/a>, was done by the book. By the way, it isn’t just for engineers. It can be used by professionals in marketing, finance, or business owners. So, we had a board of ideas, which were analyzed by a small committee. And then the finalists underwent deeper research to analyze markets, competitors, valuations, potential segments, and our expertise.<\/p>\n\n\n\n

The same thing is true with Coupler.io<\/a>. Once we understood that it could be the next thing, we launched it also by the book. We didn\u2019t build the whole platform for years but focused on smaller pieces, like data migration from one source to one destination. Then, we extended the number of destinations and sources, added a visualization layer, and so on. It was a long transformation process.<\/p>\n\n\n\n

Uniting craftspeople<\/h2>\n\n\n\n

Romeo: Coupler.io has 790,000 users, including companies like Uber and Stanford. You can attract clients by showing this and proof that if you did it for yourself, you will do it for them.<\/strong><\/p>\n\n\n\n

Sergiy<\/em>: When we\u2019ve already had Mailtrap for quite some time, we also believed that clients would line up. However, it appeared that some clients found it potentially risky. They started asking, “If your product grows better than it is now, what will you do? Will you take my team for your product?” This concern isn’t the main risk, but it’s a question that pops up.\u00a0<\/p>\n\n\n\n

Another concern is ideas. Clients worry that if we know how to build products, we might theoretically repeat their idea, which, of course, goes against our ethics. But when a company from the United States shares its precious ideas with an offshore company, they consider this risky.<\/p>\n\n\n\n

Yaroslav<\/em>: In fact, I just visited two of our clients, in Nashville and New York. The client from Nashville stressed that one of the reasons they decided to stay with us is our knowledge of crafting our own products. We are not a plain body shop. Our team knows how to execute, develop while dealing with the pressure of finances running out. So, it really depends on the client.<\/p>\n\n\n\n

Sergiy<\/em>: A couple of factors usually play into whether you win or lose a client. However, when our customer Tope Awotona mentioned our role in the success of Calendly in his podcast, which we appreciate a lot, it generated a lot of leads for us for more than a year. The most interesting was that we received high-quality leads\u2014entrepreneurs with ideas who didn\u2019t know how to build products but knew how to build businesses. This is the most valuable case for us. We can combine both worlds and craft a great product.<\/p>\n\n\n\n

Romeo: So, did you ever feel like you needed to focus on a particular industry vertical, or was it always just about the products, regardless of the industry? <\/strong><\/p>\n\n\n\n

Yaroslav<\/em>: We didn’t specialize because we are a small company. And it is also tough, if not impossible, to become a big company with high-quality people right away. To specialize, we would need to be a thousand-person company.\u00a0<\/p>\n\n\n\n

But it is better to start with a base of craftspeople and then add really great talent. We hire<\/a> around one out of 143 applicants. Most companies don\u2019t do that. As a result, we have amazing products that we\u2019ve built for ourselves and our clients. <\/p>\n\n\n\n

Our clients are completely different. Some work in the medical industry, others in calendar and satellite technologies or farming. But they all appreciate that we are conscious from day one. During the first call, we don\u2019t ask about the budget right away. We dive into the details of the product and listen to the goals. As of today, we know the best ways to launch products and the best strategies to use.<\/p>\n\n\n\n

For instance, when a product demands significant content input from the client, we acknowledge their potential time constraints due to operational demands. In response, we explore integration possibilities with their existing systems to streamline content retrieval. It might not be a perfect approach, but the product might remain unused.<\/p>\n\n\n\n

Railsware Way to Craft Products<\/h2>\n\n\n\n
\"\"<\/figure>\n\n\n\n

Sergiy<\/em>: We have a framework called BRIDGeS<\/a>, which was inspired by Pivotal Labs’ Inception. This framework is useful for both product development and process organization. It helps onboard yourself and your team into the context very quickly. Instead of conversations that trap you in circles, this framework helps you break things into pieces, discuss one thing at a time, ensure the whole team is on the same page, and then move on to the next item. This continues until you have all those elements mapped out, either physically or on virtual whiteboards. We prefer Figma<\/a> for this.<\/p>\n\n\n\n

Yaroslav<\/em>: The problem is the neural net of the person\u2019s brain who was part of a certain context or product for ten years. For instance, let’s take the satellite business. We approach it by extracting all the issues, benefits, risks, personas, goals of the business, and domain knowledge. Then, we put this neural net on the whiteboard.\u00a0<\/p>\n\n\n\n

This is worth two years of working on a product rather than reading a typical requirement spec where people combine everything. Every product<\/a> has five roadmaps: a strategic, sales, marketing, technical, and team roadmap. When you combine all of them into one conversation, it just starts to be chaotic.<\/p>\n\n\n\n

Building a great team<\/h2>\n\n\n\n
\"\"<\/figure>\n\n\n\n

Yarosla<\/em>v: We try to start with the leanest team possible. The client represents the business part\u2014sales, marketing, commercial success, and strategy direction\u2014while we represent the product and design direction.<\/p>\n\n\n\n

It typically includes a pair of engineers\u2014very rarely do we start with one engineer. Alongside, there would be a product manager, who could be the client themselves, the business owner, or our own product manager if needed. Additionally, we have a product designer\u2014and note, this isn’t just a graphical designer. So this is what a minimum viable team looks like. <\/p>\n\n\n\n

Besides, we have another concept called “the Heart<\/a>.” The heart is the minimum viable part of a product. It is important to select the riskiest part of the system, the most unknown, and build it as fast as possible. This allows the team to wrap around it. So everyone can see what the product is. <\/p>\n\n\n\n

One quick example is when we built the booking page for Calendly. We hardcoded everything to test whether it worked with Google API. Then, we had everyone in the company refresh the page to see if there were any potential limitations. This helped us understand the core functionality\u2014the heart\u2014of the system.<\/p>\n\n\n\n

The same approach was taken with our Smart Checklist<\/a>. We built a minimalistic version in three days, deployed it to the market, and saw significant user engagement. Starting with the most important and risky aspect ensures everyone understands the product, eliminates confusion, fear, and sets a positive team dynamic. It’s crucial to begin with what truly matters, rather than administrative functions, so the team remains engaged and excited throughout the journey.<\/p>\n\n\n\n

Romeo: When we looked at the software houses in Poland, we compared employee counts between 2019 and 2024. It’s remarkable that your company is one of the few that experienced growth in the number of employees. Do you believe this lean approach contributed to your growth amidst the tech layoffs?<\/strong><\/p>\n\n\n\n

Yaroslav<\/em>: Our growth stemmed from multiple factors.<\/p>\n\n\n\n

Firstly, our products were expanding. That allows us to invest more and grow them further.<\/p>\n\n\n\n

Secondly, our clients experienced growth within their teams and required more assistance. The approach at Railsware is different\u2014we provide actual help, not just occupying a seat that may or may not benefit the client. Our team members are not just placeholders. They actively contribute to delivering important elements within our clients’ products. We ensure that every team member is passionate about building products, and we never compromise on this criterion.<\/p>\n\n\n\n

Sergiy<\/em>: Many outsourcing companies often hire individuals straight from the market. So they could fulfill project requirements. For instance, if a client needs 20 engineers, they simply open the door for interviews with perhaps 60 candidates, selecting every third person to join the project.<\/p>\n\n\n\n

\"\"<\/figure>\n\n\n\n

Consequently, there’s a diversity of cultures and methodologies within the same company when it comes to writing software, managing product development, and interacting with colleagues, projects, and clients. When a client decides to terminate a project, it leaves behind a surplus of team members, including engineers, project managers, and others, who may not be suitable for other projects within the company.<\/p>\n\n\n\n

On the other hand, Railswarians are professionals who can seamlessly integrate into any project and apply our established development culture. Each engineer undergoes our comprehensive onboarding process, where they learn our approaches to software development, deployment, code review, and more. <\/p>\n\n\n\n

This way, we ensure consistency and high-quality service across all projects. We prioritize shipping and ensure that every team member adheres to our standard practices, regardless of their previous experiences. This approach not only guarantees a high-quality product but also helps us attract clients even during times of crisis.<\/p>\n\n\n\n

Check the second part!<\/h2>\n\n\n\n

The interview doesn\u2019t end here! In the second part, Yaroslav and Sergiy will discuss marketing revenue, including key metrics to measure, analysis techniques, and how to stay current with updates and upcoming plans of Railsware. <\/p>\n\n\n\n

\n