Palina Litvinkovich, an expert in project and business management, on leadership, unconventional cases, and working with unresponsive clients
The shrinking planning horizon and growing business demands are making project management increasingly complex. More and more often, project managers find themselves working in situations where there are no clear requirements, and clients are either unwilling or unable to articulate their needs precisely.
A striking case from Palina Litvinkovich, an internationally recognized expert in project and business management, involved developing a trading platform where the client flat-out refused to provide any details about the product idea. Despite this, under her leadership, the team brought the project to success by building a unique system of communication and fully taking on the strategic direction of the development.
Palina Litvinkovich began her career in IT and marketing as an HR assistant and rose to become the head of a software development department. She has built project management practices from scratch, launched business analysis departments, mentored managers, and increased project profitability. Today, she lives in the U.S., graduated with honors from a business program in Chicago, served on the jury of the Armenia Digital Awards as an international management expert, works in a digital agency, and co-runs an IT business with a partner.
In an interview with The Techbullion, Palina shared how to keep a team productive and achieve results—even when the client doesn’t clearly express their expectations.
Palina, with your experience in over 30 projects, rapid career growth, and establishing project management practices from the ground up, do you think working with vague requirements has become the new normal for project managers?
This has actually always been a reality for project managers—requirements are often unclear. That’s exactly why “agile” methodologies exist in project management: to adapt to change and adjust products on the fly in response to evolving requirements and expectations.
Today, the winners aren’t those who stick perfectly to a plan, but those who are flexible and can adjust a plan in complete uncertainty. So adaptability, initiative, and the ability to take ownership are no longer nice-to-have but rather must-have qualities for any project or product manager.
With market turbulence, growing competition, and ongoing internal shifts, companies are often forced to move fast and adjust on the go. This was especially evident from my experience working on the trading platform project a few years ago. The client came to us with an idea to expand their product but didn’t want to share the full concept with us, refusing to provide any clear requirements besides the one-line idea.
As a department head, you’re often required to make strategic decisions during product development. How did you adapt your usual methodology under such uncertain conditions?
It was definitely a challenge — the client provided no specifics whatsoever, and in such cases, traditional approaches stop working. Instead of the usual process of gathering requirements, creating prototypes, building UX/UI designs, and then developing the product, we started by exploring hypotheses of what the potential product might look like — in a complex fintech domain that requires very specialized knowledge.
At that time, our team didn’t have deep expertise in that particular domain area, but we had a strong desire to understand and genuinely help the client.
We used an iterative approach: first, having access to the client’s existing platform, we reviewed the functionality it had. Then, we gathered ideas — how we envisioned the product and what functionality it might include. After that, I approved every single point with the client via email, phrasing questions in a way that allowed only “yes” or “no” answers. After getting alignment, we designed several completely different wireframes to make sure we were actually building what the client wanted. Only once the designs were approved did we proceed with standard development — regularly presenting results and adjusting as needed.
You started your career in HR during university, worked your way up through business development to leading projects and entire departments. How has your background in marketing, sales, and recruitment influenced your project management style, especially in unconventional situations?
My cross-functional experience has often given me a broader perspective than that of a specialist focused exclusively on project management. I could look at challenges from different angles — assist sales teams during the presales process, explain to software engineers why certain things mattered, and understand the client’s viewpoint. This multi-angle vision helped me find creative solutions in atypical scenarios.
It also shaped my ability to grasp what both the team and the business need — even if it’s not clearly articulated. I can quickly read motivations, ask the right questions, and view the project not just as a list of tasks but as a business tool with strategic goals.
As an experienced leader in the digital sphere, you served on the jury of the Armenia Digital Awards, evaluating participants’ accomplishments. Given your recognized skill in assessing talent in the IT space, what was your approach to building a team for this project?
I built the team not only based on experience, but also on proactivity, resilience to ambiguity, and an ability to navigate uncertainty. We needed people who were ready to think for the client, propose solutions, and not be afraid of the grey areas.
For a manager in such projects, key qualities are unconventional thinking, empathy, high adaptability, and the ability to stay calm amid chaos. People naturally follow someone who radiates confidence — even if we’re feeling our way through the process ourselves.
You essentially took on the role of a product owner by shaping the requirements yourself. Which planning frameworks or approaches proved most effective in such unconventional conditions?
What was truly unconventional was our approach to requirements gathering: instead of following the standard process of studying a Specification Requirements Document or collecting requirements with the help of a Business Analyst, we took on the role of the Product Owner ourselves. We created the functionality on behalf of the client and then validated each feature with them to get confirmation that it was exactly what they envisioned in their product.
We used a lot of visualization to make sure we’re on the right path: different diagrams & user flows, multiple prototypes, wireframes, and designs. On a weekly basis, we aligned with both the team and the client to track progress. We also provided regular status reports for the client to ensure alignment with their evolving vision.
After completing the project, that same client returned a year later with a new project, as he was convinced that only you could handle it. What do you think earned you that level of trust?
We didn’t just “deliver a project” — we took the weight off the client’s shoulders. He realized he didn’t need to micromanage or monitor every single step. We took responsibility, kept up the pace, and stayed flexible, always adapting to his wishes — even when they weren’t clearly stated.
Without him even fully realizing it, we aligned the entire project with his vision, finished the design part — which he absolutely loved — and developed everything in terms of functionality that he wanted to have in his product within the agreed timeframe.
What key lessons did you take away from this project? What would you advise PMs who are working under high uncertainty or with “silent” clients?
Don’t wait for clarity from the client — take initiative. But also, validate every single step. Even if something seems logical, make sure you get explicit confirmation.
Projects like this are opportunities to truly test your skills and push the team’s creative thinking. And by the time it’s completed, you’ll notice how capable of handling even more interesting challenges you’ve become.
And most importantly, keep things transparent within the team. It’s critical to explain the business context of the project so that the team understands the why behind what they’re doing. The higher the uncertainty on the outside, the more stability you need on the inside.
I actually later used this project as a case study question when hiring new project managers for our team. And thanks to it, we were able to filter out the candidates and hire only the best.
