Eva Dimitrova

My specialty is in taking digital products and services from 0 to 1. Whether it’s to position them in a competitive market, to help build them or to create and execute a go-to-market strategy.

I’ve worked with Vodafone, Google, Amazon, Microsoft and IBM on launching more than 30 international software projects. I’ve also been involved in multiple startups, including as a founder.

Those experiences combined with my love for learning and overcoming challenges is what feeds my creativity for solutions and innovations. Are you looking for one?

What did 30 projects teach me about successful digital product management

What did 30 projects teach me about successful digital product management

From German: concept yourself! Made by  Dimitri Nachtigal .

From German: concept yourself! Made by Dimitri Nachtigal.

Reading time: 4 minutes

In the last couple of years I had the opportunity to work on more than 30 chatbot and voice assistant projects at Vodafone. What started as hard-coded demos turned into a top-priority digital global operation in just over 12 months. Soon we were supporting markets around the world with the launches of their TOBi chatbots, Alexa skills and Google Assistant apps.

Pioneering the adoption of an AI technology and seeing how the work evolves was a fascinating and diverse experience. While some projects were extremely successful and smooth, others dragged on for months.

What I found valuable was learning what makes or breaks a digital project, especially from the perspective of a product manager.

1. Know when to change focus.

New feature requests could be the life or death of a digital product. In the early stages it is almost inevitable to explore different ideas. And you should! Finding product-market fit means finding people who are genuinely interested in your product. No people, no product. No product, no business.

But when you find them, the idea-searching phase has to halt and a new process needs to take place - make the customers happy. Consistently happy.

Meeting someone’s needs to the extent that they invest their time and money in your product, creates a fundamental expectation - to always have those needs met. It is especially true for B2B customers, who on one hand need to change their processes and on another has a lot on stake if something breaks.

Too often, though, due to various reasons, the opposite happens.

New ideas will always circulate - either from the management, the clients themselves or from within our own heads. Nonetheless, it’s crucial to double down on building a stable scalable environment first. One that is reliable and can support further feature development without compromising the existing functionality for the existing customers.

2. Overpromise is bad.

Talking about ideas coming from above…

In bigger companies there are multiple management levels and only the bottom operational layer is hands-on building stuff. Though the products are made for customers outside of the company, very often they become the cake that every stakeholder wants a piece of.

Many of those people would come with ideas and suggestions on what the product could do. At those moments it’s easy to overpromise. But in my experience that rarely comes to a good end. It usually ends up eroding the trust of your team, manager and customers, while at the same time puts an immense work load on the team.

It is hard to fix a half baked cake, as it is hard to sell it. Better to instead be clear about the time required to build something and keep the expectations realistic. It’s always merrier when you overdeliver, rather than overpromise.

3. Align well or die.

Communication is without a doubt at the core of everything. From explaining the value of your product to your manager and customer, to writing requirements for a new feature.

But not only that.

In a typical big-scale company, digital product development implicates the following departments:

  • Commercial (Product, Design and UX),

  • Technology (multiple sub-departments and teams responsible for APIs, authentication, DevOps, Q/A, Reporting, etc),

  • Legal, Privacy, Security,

  • Consumer or Enterprise,

  • and other, that are specific to the industry of the company.

There also are external parties involved:

  • different solution providers (for example an external development team or a design agency),

  • freelancers and consultants,

  • and partners, who may help deliver the product on their platforms.

In some cases part of the development is split between the parent company and the local companies, aka local markets. That can up to double the amount of people involved.

Aligning on the current status with everyone is crucial. It’s a manual and time consuming effort, but it makes a stark difference. Here are some winning practices I noted down:

  • Bring people on the “same table”. Whether it’s Slack or Microsoft teams, make sure everyone is there so the discussion can happen smoothly. Not everyone can join face-to-face meetings or calls, so this is the second best alternative. Depending on how active is the communication, it might be better to have a dedicated channel for each team/topic, so that the conversation is easily traceable.

  • Use email lists. Email lists are saving plenty of time and you will never worry if you missed someone. The cost of having people blocked or misinformed for a day or two might not look very high now, but it can in just few months accumulate in weeks worth of lost time and money.

  • Maintain and share documentation. Shared Confluence pages and Github repos not only help onboard new teams and members, but also make a new project kick off so much faster and easier. And I’m not only talking about technical details, but also standard procedures, team structure and internal release notes. There is nothing pleasant about being called during your vacation, because you are the only one who knows something. And there is nothing pleasant when you have to make that call.

And finally…

4. Celebrating makes you stronger.

Nothing brings people together like sharing a good emotion. And no team works as good as a happy team.

So if you have a reason - celebrate. If you don’t have a reason - celebrate still. Because every day that you and your team push to build a better product is a day worth celebrating.

Cheers to that!

Product management while facing death

Product management while facing death