How we work at Pragmatic Coders
They say that a good post on a company blog should be transparent. It should give you the knowledge you can apply and ideally not mention the company it comes from at all. But. This one is going to be different. Because this one is going to be about How we work at Pragmatic Coders. (And why we think it’s the best possible way, OFC).
We are not just a software house
Yep! You’ve read just right. We are not very keen on calling ourselves a software house. Instead, we prefer the name Product Development Company. Why is it so important? Because we work on products, and not projects. Does it change anything? Actually, yes, it does.
When you work on a project, you follow someone else’s vision and orders. You are a builder, and you are treated as one. If you hate the job… So be it. Ship it. Get paid. Forget the experience. (Or start again).
And there is absolutely nothing wrong with such an approach. But we know there are much more efficient ways of building products and growing startups, and we prefer to use them instead.
What are we after, then?
We want to be partners in building your product. We want to share our experience with you. Trust us; we’ve seen tons of different businesses. We know what to do to make your odds of succeeding go up. We walk you firmly through all the steps of founding a startup. We know how to prepare a killer pitch deck, we know who you should show it to, we know all about the development, and we are no strangers to scaling up.
Don’t expect us to write code from day one. Instead, we invite you to have a conversation about your product. Heck! We can even start by explaining why it’s so important. We need you to meet us with an open mind and be ready for two-way communication.
We ask (difficult) questions
Has anyone told you that there are certain things you need to prepare BEFORE you start developing your product? No? All they wanted from you was the list of requirements? We know it all too well.
Here is what we do. We start working with our clients by asking them tons of questions. We even wrote some educational pieces on how and why you can prepare the answers. Still, there are a lot of founders who approach us without this knowledge. Believe us or not, but we embrace them. Especially when they are open-minded and knowledge-hungry.
So, in a nutshell, what are those challenging questions that we ask? Are they about budget? Timeline? Team? It’s 3 times “no.” They concern about the product you want to build with us.
We want to know everything about:
- What is the problem you want to solve?
- Who do you want to sell it to?
- Why should they choose your product?
Those three W-questions above are, of course, just the beginning of the more extended interview. Nevertheless, they get us a good overview of what you are planning. And, if you don’t know the answers just yet, we will help you find them (see the next section).
We help you find the answers
Let us tell you a secret. We really enjoy working with clients who know there are things they don’t know. It’s fascinating to guide them through the process of inventing their product and business model.
If you like looking at specific examples – feel invited to check out the Duel case study. It’s the story of how we took the client’s idea, turned it upside down, and created something very different from the initial conception. All of the above took place in full cooperation with the client, obviously.
But let’s leave the Duel team be (and wish them good luck as they just got their funding) and come back to find the answers you need to start building your product. Depending on the amount of help you need, you can either spend some time on fruitful chats with the product owner (PO) assigned to your product or participate in an intensive Product Discovery Workshop.
If you only need some guidance, the meeting with the PO should do the trick. They will steer your train of thought down the right track, and that’s it. However, if you are feeling a bit in the dark, the Product Discovery Workshop might be a much better idea. Let’s say it’s a more intense experience.
Anyway, in both cases, the desired outcome is the same. We want you to have three documents ready. It’s our basic checklist for starting the development phase:
With those three in place, we can say we know where we are going. We don’t need to waste developers’ time wandering without direction. We know the goal, and we want to get there fast and safe.
With those three in place, we can say we know where we are going. We don’t need to waste developers’ time on wandering without direction. We know the goal, and we want to get there fast and safe.
Validation – just do it
Have you ever heard this old but gold business saying, “You have to spend money to make money”? It’s impossible you haven’t.
We have a new one for you. Sometimes you have to spend money to save money. You think it doesn’t make any sense? Let us explain.
It all goes down to the concept of validation. Meet Matt. Matt has a product idea. It looks great on paper. People will undoubtedly go crazy about it. Or at least, so he thinks. He starts building. He invests time and money – lots of them. And one day, finally, his product is 100% ready. Matt is so fricking proud to release it. But nobody else cares. Nobody is buying.
We know it’s the situation every founder dreads the most.
But what went wrong?
Matt didn’t validate. He didn’t validate his product idea. He didn’t validate during development. And when he finally did validate with the market, it was too late. His product wasn’t something people needed.
How does it translate to saving money by spending it?
Let’s go back to our friend Matt. Imagine he decided to build a prototype of his product. He spent a fraction of time and budget on it. Then he showed it to some people. He validated his product. The public told Matt his product was not too good and they wouldn’t buy it. It’s easy to imagine Matt was heartbroken. From here on, this story might have two endings.
- Matt conducts more research and comes up with the idea of a product with a better product-market fit. He builds a prototype using a fraction of the remaining budget. He validates it and gets the green light from his early adopters. He eventually founds a successful startup around what he created.
- Matt decides that building products is not his cup of tea. He takes the remaining budget and does whatever he feels like.
We think that Matt’s a winner in both scenarios. We will tell you why in the next section.
Seriously, just do it
All three variations of Matt’s story seem to be relatively straightforward. We admit, writing them was not about creating cliffhangers and a surprising turn of events. To tell the truth, the turn of events was typical to the bone. But there is one thing we would like to bring to your attention.
Think of how furious and frustrated Matt must have been when he decided to validate his product only to discover that there was no demand for it. It’s tough to look for the bright side when your fabulous product idea turns out to be… well, not necessarily so fabulous after all.
We encourage our clients to change their perspective. The earlier they know they are going in the wrong direction, the more time (and budget) they have left to react. Pivots happen all the time. They are something to be proud of and not despair about.
Sometimes we work with clients that refuse to validate their hypotheses. Are we mad at them? No. Not at all. It saddens us deeply. We hate seeing them heading towards the wall at full speed. We know the wall is there, and seeing them ignoring our warnings is just painful. Not nearly as painful as crashing at this wall, though.
Ok, that might have sounded a bit too dramatic. We admit that there are cases where such products do well on the market. Yet, we have to stress the fact that in this scenario the costs of development tend to go up.
Go live, now!
Going live is one step further down the validation road. We hope we’ve already convinced you to validate your product ASAP and then again and again at every stage of development. But when is this one, single, perfect moment to release your beloved product to the public?
We have bad news – there is no perfect timing. This is precisely why there is a notion of an MVP (Minimal Viable Product). The MVP is, by definition, imperfect, so you don’t have to worry about that.
One of our founders – Wiktor – likes to say: “If you are pleased with your MVP, it means you’ve released it too late.” We couldn’t agree more (and this is not only because he is our boss).
But we already have two chapters about the need for validation. So why bother about the MVP at all? It’s because it’s vital to us that our customers understand that an MVP might be a dozen of different things. In a nutshell, there is no recipe for a perfect MVP of your product. This is precisely why we start cooperation with new clients from understanding their idea of a product we’re building.
It allows us to suggest the best possible solution for an MVP and the best timing to show it to the public.
We promise to get your product live in less than 3 months. To deliver on this promise, we need to set the priorities right from the very beginning.
Scale up thoughtfully
Ok, we’ve told you all about the need for validation and how we promise to build something you can show in less than 3 months. But what happens next? Let’s say your MVP was a huge success. It was, right? It must have been since you’d constantly been validating your product idea throughout different stages of development. Good for you!
So, what comes after the initial success?
Work.
Once the champagne is all drunk up and the fireworks are over, it’s time to get back to work and build some more. After all, MVP is a Viable Product, but it’s still Minimal.
- Smart scaling up requires a two-fold approach.
- You need to make sure your basic product is stable and ready to grow.
You need to add more features.
Let’s start from the first part. When you want to build something that appeals to the public fast or even blazingly fast, you need to cut some corners. It’s important to revisit those corners after the launch and make sure everything is scalable and elegant. This small step can save a lot of work in the future.
We know that adding new features is much more exciting than tackling some underlying technical issues. Yet, we believe a good tech partner should always make sure there is a good balance between fancy and necessary.
Let’s celebrate!
Congratulations! It seems that at this point, you are a founder of a successful startup. It might not be a unicorn, but who knows…
This is exactly what we want. We are not after your money; we are after your success. We don’t want to earn money building products we don’t believe in. We want to be partners in creating things that matter (or at least that sell well).
That’s why you can count on us at every stage of the process. That’s why we call ourselves a startup consultancy. The idea is all yours, but let’s make sure it’s executed in the best possible way
Author
