Analysis, design, building towards an MVP, choosing tech stack, establishing maintenance cadence, managing technical debt…Vladyslav Tsyrkun, Senior Front-End developer at PYGIO, shares his views on the nuances of product development. This interview was super personal and self-reflective. We hope you’ll dig it.

What is your role at PYGIO?

I am busy working as a Front-End developer for a project, where we build a gamified sales application for a telco client. 

What project are you working on?

The product aims to add a scientific process to the sales function. This is a workflow-oriented application; the idea is to incentivize salespeople and keep track of each sales agent. The app will help facilitate the management of franchisees, managers, and agents. Leveraging Machine Learning techniques, we are able to utilise this sales data to infer and instruct better sales behavior.

Tell us about yourself and your career leading up to PYGIO.

As a kid, I spent a lot of time playing outside but I also loved maths and physics a lot. I took extra computer science courses, introducing us to different programming languages, which prepared me for university exams. I joined Igor Sikorsky Kyiv Polytechnic Institute, the best technical university in Ukraine. Among other top tech institutes, I can name the National University of Kyiv-Mohyla Academy and the Ukrainian Catholic University in Lviv.

At university, I wanted to learn as much as I could to understand what works for me the best. So I studied both Front-End and Back-End and that was a huge mistake because I couldn’t focus on one thing. Eventually, I chose Front-End and to this day there are many things I want to learn in this area. 

I started my career in a product company from Australia. I was busy creating a platform for cryptocurrencies with prediction functionality. After this, I spent a couple of years working for Ukrainian outsourcing companies and then joined an American metaverse startup. 

Can you explain what it takes to build a product? From the Frond-End perspective of course. 

The number one requirement is to understand what a user needs from a product or service. Mistakes are made when the Product Owner’s (PO) vision of the product ultimately misaligns with how the consumer actually wants the product to solve their problem. This is the hard thing about building and the classic dichotomy of “build it and they will come” vs “build a pre-MVP and gain user feedback, risking reputational damage” is an eternal debate in start-up land.

Additionally to the chicken-and-egg problem described above, conveying product ideas is like playing broken telephone. The product may look great on paper or in the PO’s head, but in reality it may not solve the intended problem. 

It works like this: first we unpack the PO’s vision and his plans for a future product. To cement an MVP design and criteria of success, we begin with:

• Figma UX/UI prototyping – visually represents what the product should look like, work, and flow.
• Business system analysis – defining the “blueprint” of the product, how it should be used by end-consumers and what the intended roadmap is.
• Architecture – mapping entity relations based on the early-stage requirements and approving this with a PO.
• If there is an existing code base, we often perform a system review to understand how to improve and scale the product.

I’ve made plenty of mistakes, so I know that if a user can’t find a button on a menu, the UI needs to be revised. If it takes minutes instead of seconds to find the necessary info on the site it means “Houston, we have a problem”.

As a Front-End professional and enthusiast, my task is to show a PO what to look for in their product and customer usage patterns – to infer how to adapt and evolve and sometimes delete some features. At the back of my head – I am thinking – time, effort and money – how do we maximize these to arrive at the intended result (and make things look good).

It’s a funny thing about how my brain works – I’m testing apps even if I don’t have to – in my everyday life. I test as a user and make mental notes if this or that solution is cool, if this button or interface is great, and how much time it takes to browse what I need.  

Researching and testing new User Experiences and User Interfaces on apps is now my way of digital life.

I collaborate with designers intensely because my eye is trained to see the functional subtleties of each product. In this engagement, it’s crucial to give constructive feedback backed with references, articles, and research. Not just saying “I don’t like this colour”, but explaining “Why does this particular shade not look flattering in this particular case”. I make sure I use a well-known “sandwich method” that includes a “praise-criticism-praise” sequence. Respect the creativity!

What are other product development stages?

The next step is to build the application and try to make it as simple as possible, while solving the user’s overarching problem.

• Implementing architecture: we think about the code structure, database interactions, libraries or plugins, third party integrations and more.
• Delivery: choosing the most suitable development cadence and team structure for a particular product build is critical. Strong delivery people (Project Managers) is a must.
• Tech stack selection: we research strategies developed by the top minds/ experts who tried a particular technologies. Sometimes it makes sense to keep the old technology that works instead of jumping into half-baked new updates. 

For example, I tried to use the Vue framework. It was still new a number of years ago and was unfortunately not sufficient for our needs. I didn’t expect that result but we learnt that it was still raw and it didn’t have robust integrations with new libraries. We had to manage different versions of libraries to make them stick together. And then we realized that it was a mistake and that the version we used was not ready for production level despite its cool features. 

• Maintenance: aka fixing mistakes. Oh, we’ve been involved in a lot in the maintenance. What we like about bug fixing is that you see the result: improved performance and user experience being enhanced.

To me this work is like solving a math problem, it stimulates you to think, explore, learn and eventually – aha – the bug is fixed and everything is running nicely. Until the next bug 🙂

What about technical debt? Is it better to leave your code as is and move forward?

Situations when you have an urgent task and you use a shortcut method for writing your code happen all the time. 

For example, you developed a cool new feature to be used only for Christmas week. Suddenly it stopped working and you applied a hotfix. And it’s okay for the time being, but you need to redo it eventually. It should be included on Jira with an associated time allocation to *eventually* rewrite the code properly.

You said that Front-End is constantly developing. What are you keen to learn next? 

My main motivation is to improve the quality of each product I work on. Usually when newer technologies have extended functionality, I try them to deliver better code. I am currently using the JavaScript framework. And as the new version of it came live I am busy learning and implementing it straight away. By learning I mean studying documentation, Googling (or ChatGPTing) expert opinions and testing on pet projects.

Tell us a fun fact about yourself! 

I made a lot of friends while hitchhiking throughout Europe one year. I was living in a strangers’ apartments using a couch surfing platform. The main reason I did this was because I was looking for some real-life experience and meeting new people. 

Through couch surfing you find out way more about other people’s cultures. The locals can show you cool places you would never see by traveling conventionally. 

This is so cool. And my last question will be what is your biggest dream right now?

My biggest dream is that Ukraine wins the war and we all go back to living in peace. It’s my most cherished dream right now and I don’t even have to think for a second to give you an answer.  

Beyond this dream, I love working at a company that inspires people like me to build exceptional products, and gives us the free space to experiment and test solutions that ultimately benefit the product and customer.

There is no “one-size-fits-all” when building a product, but I hope the above provide a framework for getting from Chaos to Concept.

Got a question or have a product idea? Submit your request to our contact form.