Interview with Natallia Shauchenka (Senior PM @ BCG Digital Ventures)

To kick off this interview, can you tell us what companies you have worked for?

I have worked for a couple of eСommerce players like Monoqi and Outfittery, and currently I am building products for corporates at BCG Digital Ventures.

Would you say that all great products have been built by great teams?

I think there have been equal amount of great products built by average teams and average products build by outstanding teams. I do believe that there is a lot of serendipity in building a great product.

There's a lot of serendipity in building a great product.

What are the qualities of a great team to you?

I find a healthy amount of respectful disagreement to be one of the key features of a great team. Being able to challenge each other ideas is extremely valuable and helps to weed out mediocre ideas.

I also noticed that teams which do not obsess with roles and titles and do not fear to pick up tasks from other domains if that's the right thing to do at the moment produce much more solid result.

And fun of course. Having a good laugh even in the most stressful situations is very important.

Having had experience with multiple products, what are the things you would never do again?

SOOOOOO many things!

• Overcomplicate things. Try to come up with The Perfect Solution from the first try and cover all the edge cases
• Roll out a solution which kind of works, but still requires the user to suffer a bit
• Listen to theorists and "experts" who did not build anything significant. Compromise on things if my gut tells me not to.

Can you tell us about a widely accepted idea that you believe is overrated or wrong?

Design thinking is the silver bullet for all sorts of products and teams.

In my experience, it often ends up being quite prescriptive and limits the possibility for exploration and for actually thinking out of the box. I also feel like at times design thinking is used to cover the lack of craft and expertise - we (as product team) just hand off the solution design to the user under the flag of empathy, instead of actually doing our homework thoroughly.

In many cases you can achieve 80% of the result with 20% of effort. In others - you need to go all the way. How do you decide when to stop?

If the extra effort goes completely unnoticed, or if the change in the metric you are targeting is disproportionally low compared to the invested effort - it is probably a good time to stop.

You now work in tech, but digital products are a relatively new thing. What would you do, had you been born 50 years earlier?

I'd probably either be a flight attendant or work in entertainment industry. Someone would need to coordinate all those disco folks to get the Saturday night fever going.

What apps do you have on your Home Screen?

Bookmate, Notion, Trello, Toggl, Komoot, iNaturalist and Headspace and all the communication apps are the standard. I download a few apps a week - currently I am obsessed with mindfulness and wellness apps. My favourite of the last weeks is Welltory. They are using the phone flashlight to measure your heart rate variability - not sure I trust the accuracy of it entirely, but I found the solution itself to be super neat!

What is your favourite product that hasn't become mainstream yet?

It's a tough one. I have a few favourite products that I do not use, but love the idea - LabTwin and OneSoil to name a couple. Frankly, I do not think they will ever become mainstream, because they are focusing on very specific problems (scientific research and farming respectively). None the less, I watch them closely and cheer for them because their aspiration resonates with me, I like the teams behind these products, and the way they communicate their values and products is just inspiring to me.

What's your favourite Jira alternative?

Physical kanban board beats Jira any time ;) on a more serious note, Trello gives more flexibility and incorporates issue-specific knowledge management quite well. I love using it for my own projects, sadly it never took off with any development team I worked with.

Unpopular opinion: I actually don't hate Jira. It takes a moment or two to set it up well, but I made good experiences with it managing 3 products in parallel, and I value the possibility to connect an issue to related knowledge fairly easily.

Many products that do one thing really well or one product that is ok at many things?

Many products that do one thing really well - focus is the key to excellence.

Where are you on the scale from "Deploy early and often" to "Only deploy when you are 100% sure there are no new bugs"?

Early and often on staging, much more careful on production.

I have been mostly working with B2B products and internal software solutions, and one thing I've learned is that users that are forced to use your product are a very unforgiving audience.

How much do you think the culture of "Move fast and break things" has affected the quality of modern products?

It is terrible. I recently listened to Jonathan Blow's talk from DevGAMM 2019, where among other things he talks about recording all the software bugs and issues he experienced in a day. Bottom line: we do not even expect software to work any more.

We are so used to it, that we do not notice it in day-to-day app usage, but when you think how much of our life depends on the software - it just becomes really scary.

We do not even expect software to work any more.

How do you approach Quality Assurance in your teams?

At DV (BCG Digital Ventures), engineering teams put a lot of emphasis on quality as a part of the development workflow, through processes like peer reviews and marinating a certain level of test coverage in code.

We also encourage the teams to use the products they are working on frequently to spot unobvious issues, and we host regular bug-bashing sessions before major releases.

How do you like to split testing between Product Managers and QA?

So far I did not have too many opportunities to work with QA. So in most cases I do testing for the functional requirements while engineering team takes care of non-functional requirements.

What makes a bug report great?

Enough detail for developer to get a few ideas what might be the problem makes a great report. Be it screenshots, console messages, or video recordings, the idea is to not have developer to spend extra time figuring out what the problem is, but focus on investigating why it occurs and how to fix it.

If tomorrow your whole team could spend 0 time on bugs, where would you invest those time savings?

On fixing technical debt and making the product stable and secure.