10 traumas from Project to Product

This article is a result of preparation to the Product Tank talk. Thanks for the opportunity to think about my experience and tear apart old wounds.

The door closed behind my colleague, leaving me alone in the meeting room. For a while, I stared after him, mulling over our coffee chat. “I want to find a place with a more product-oriented approach, and I advise you to do the same” — what does that even mean? This happened about five years ago, and I still haven’t gotten a straight answer from anyone. But even now, the search for this El Dorado called “product approach” remains the top reason for people leaving companies.

I can’t bring myself to call this new, because these practices have existed for a long time: weren’t we identifying our target audience back in the 2000s? Did we only start collecting data 5 years ago? Were iterations and experiments invented yesterday? Nah, all of this has been around for ages, it’s just now starting to come together into some structure, and people love structures.

Especially when they help giants like Microsoft, Amazon, Lego, or Nintendo to increase profits, conquer new markets, and share their wisdom with us. But the reasons for the failures of Kodak or Nokia can now easily be traced to the absence of a product approach, so the theory works both ways.

And here’s what I’ll tell you: I’ve been with EPAM for a good 8 years now, and I’ve been in this dangerous business for about 15 years total. During this time, I’ve digested a wide range of experiences: I’ve worked in the studio grind, developed products before they were even called that, and also dipped my oars in enterprise waters. But it wasn’t just the company where I worked that changed, it was also the world around us, the recognized methods and work processes. These metamorphoses have left me with a series of indelible scars and psychological injuries, as a cautionary tale for those who think that instilling a product mindset is a walk in the park. These are what I’d like to share with you now.

Project VS Product mindset

Well, let’s start with the fact that the term “Project mindset” doesn’t exist. I made it up simply to distinguish the outdated approach to product development from the trendy and popular “Product mindset.” Although, come to think of it, even “Product mindset” is an umbrella term for all the proven product management practices gathered under one roof. You can work on a project using product approach practices, or work on a product but actually approach it like it’s the 90s.

In short, it’s not a discrete system, like a disease: “Doctor, what’s wrong with me?” “I’m afraid you have Project mindset, and there’s nothing we can do about it. Hang in there!” No, it doesn’t work like that.

I haven’t come across a clearly defined checklist of “Are you a trembling creature or do you have the right to call your mindset product-oriented?” And even if there was one, it certainly wouldn’t consist of just one criterion. So, we can confidently say that the question isn’t whether you “Have it or not,” but rather “How much you don’t have it,” from “not at all” to “just a tiny bit.” And so, weighing all the pros and cons, I realized that the world simply needs such a checklist, because we love them, don’t we? So, after pondering a bit, I came up with my list of differences. Don’t scold me if it seems incomplete to you; I’m just a designer, what can you expect?

Here is what I think about Product vs Project:

1. Definition of success: The outdated approach is characterized by the desire to “complete all the work.” Since we’re used to working in conditions of minimal uncertainty, a project is considered successfully completed when all tasks from the backlog have moved to the “Done” status. In contrast, the product approach doesn’t even consider the possibility of finishing something. Instead, a product is only successful if it constantly increases user and business value.
2. Locus of focus: Projects are self-absorbed, worrying about meeting deadlines, pleasing stakeholders, and not falling apart along the way. They couldn’t care less about what’s happening outside their rainbow hellish bubble. Products, on the other hand, are focused on the external environment and are significantly influenced by the market and external circumstances, so they closely monitor what’s going on out there. They also see themselves not as isolated islands, but as part of a larger ecosystem, and are more willing to integrate with other parts of it.
3. Progress tracking: This one’s simple, as projects are based on tasks and various burndown charts, while products focus on delivered value. For the latter, it doesn’t matter how many tasks and epics need to be created and completed; what’s important is how much value you’ve provided. And this leads to the next difference.
4. Use of data: Project thinking implies limited use of data, particularly for justifying project initiation. Products, on the other hand, are packed with sensors like military fighter jets, measuring the impact of every sneeze on performance metrics.
5. Time perspective: Projects are seen as finite and time-bound through the ancient and subtle art of breaking everything into tasks and estimating them. Products also have estimates within iterations, but they don’t limit the time horizon, as there’s no limit to perfection, and your product, like Hugh Jackman, should keep improving until its dying breath.
6. Attitude towards changes: Both projects and products initially exist in conditions of uncertainty. The difference is that a project views any uncertainty as a risk and organically wants to get rid of it, hiding behind estimation tables, roadmaps, and plans. A product, however, sees uncertainty as an opportunity to increase value, and thus dives into the depths of this darkness hoping to unearth something valuable. Take feedback on results, for example. If it’s good, there’s no problem, but if it’s bad, the attitude changes immediately. A product sees it as an opportunity to improve and steer the result in the right direction. A project, more often than not, will ignore negative feedback because it contradicts the current vision, and contradiction equals uncertainty. And who needs that?
7. Innovation: Projects have a limited budget because their development is “calculated” and a specific amount of money is allocated for it. That’s why projects don’t like it when new ideas appear on the horizon — after all, everything’s been agreed upon already. Often, a project is part of an existing ecosystem with its own limitations, making it impossible to rewrite everything using new technologies. That’s why Delphi developers are paid so much — no one knows how it works anymore, but it still needs to be maintained. Products, as you might guess, more easily bulldoze through their parts not only at the feature level but also at the architecture level, just to improve metrics. The team conducts more experiments, which should ultimately have a positive impact on flexibility.
8. Scalability: Unfortunately, as we’ve already understood, projects are heavily tied to the allocated budget, and often, to meet deadlines, scalability is sacrificed by using quick fixes. Have you often heard the excuse: “Let’s leave it for post-MVP!”? Ah, that sweet lie to ease one’s conscience, because there won’t be any post-MVP. Instead, there will be a new round of functionality that will become an unbearable burden on those quick fixes. This means the RTB will grow, and new features will become increasingly expensive. It’s not that everything is rosy in product development, but technical and design debt are treated more carefully here, as they understand that prevention is better than engine replacement.
9. Stakeholder involvement: The project approach doesn’t involve active engagement of stakeholders in the development process itself; they’re left only to be informed that everything is going well and to accept the final result. In products, however, the stakeholders’ asses are on the line, so they’re elbow-deep in every iteration and involved in the process to the extreme. This, of course, can’t help but leave its mark, both good and bad.
10. Decision-making: “We follow the plan bequeathed to us by stakeholders; even if everything around us is on fire, the plan will lead us to a safe harbor” — many project managers repeat these words to themselves, not realizing that sometimes it’s necessary to abandon incorrect strategies. In product development, everything is different — the philosophy of evidence-based decisions rules. Whether it’s quantitative data from connected analytics or qualitative data obtained through interviews — they show what to do next. It’s data, not the manager’s gut feeling.
11. End users: In a project, the involvement of final consumers is very limited, precisely because it can lead to such unwelcome changes, and more often than not, this phase of the project is thrown out as unnecessary. At best, only during the testing phase, or even post-release, do we learn whether the project is headed for failure or success. In product development, on the contrary, everything is subject to an iterative approach, with each cycle including user feedback. They are involved always, everywhere, and as often as possible.
12. Group dynamics in the team: To compare approaches quickly and concisely, in a project, people just do the work, and if at some point they’re transferred to another project, they won’t grieve. In product development, the team cares about it, puts their soul into it. This means they’re ready to make it better, even in their free time. If ideas for improvement arise, the team has the autonomy to implement them, instead of saying “it’s not my business.”
13. Professionalism: In a project team, people have a clearly defined scope of responsibilities that they’re not willing to go beyond, as that’s where another person’s duties begin. Or they’re simply not paid for it. This creates a situation where there’s a dedicated person for each piece of work. In product development, the team is much smaller and represents a squad of multi-instrumentalists, each of whom can perform the functions of several roles at a sufficient level of quality. Iterations are faster — and so is professional growth.

So, these are my 13 points. If you, as an honest person, have discovered that somewhere things are not happening quite in a product-oriented way — don’t get upset. I think more often than not, when someone says they follow a product approach, it’s likely we’re dealing with some kind of hybrid. Where at least one of the product criteria will be out of place. Later we’ll learn that even following these canons may not be enough for success, or they may even work against you. Nevertheless, I can say that this approach, while not a panacea, significantly increases the chances of success for your venture.

Plan to implement product mindset:

To be honest, I’m not a product manager, so I’m not sure how valuable my opinion is here. However, to transition to the most interesting part with injuries and post-traumatic syndrome, we need to understand how it happens by the book. So, if you open any article about product mindset, here’s most likely how you’ll be advised to structure your work:

1. Preparation — uncover potential value for the business and user using domain, field, and competitive research.
2. Form a vision, a success story you want to achieve in 3 years — what will your product be like?
3. Define the North Star — a single success indicator that will determine how well you’re progressing towards your goal.
4. Determine the strategy — a set of specific milestones to overcome on the way to your goal, don’t be too specific — it’s detrimental.
5. Form KPIs for each element of the strategy to evaluate progress.
6. Align expectations of all stakeholders (by the way, they should directly participate in points 2–5).
7. Allocate necessary resources — gather teams, delegate authority, and ensure their alignment.
8. Within teams, organize a feedback cycle where the team forms hypotheses, tests them, receives feedback, implements them, and tracks success. It’s important not to interfere with teams determining their own ways of achieving KPIs for their assigned piece of strategy.
9. Measure progress and review the strategy every six months.
10. Repeat the process as you significantly approach the goal or after a long time.

It would seem like a foolproof plan. But unfortunately, it works on paper, and in real life, its implementation directly depends on the degree of rigidity of your state. If for new products the implementation is quite painless, then for old-timers as solid as a monolith, the process will resemble turning into a witcher, involving strange substances, magic, and sacrifices.

Traumas and Lessons learned:

Unfortunately, as with any trend gaining popularity, many people want to “hop on the bandwagon” of the product approach, describing how great they’ve set everything up and how awesomely it all works for them. Many even create meta-analyses of successful examples and churn out articles like “3 Steps to Success” or “Implementing a Product Approach in 10 Steps.” But the catch is that everyone looks at isolated success stories and turns a blind eye to the hundreds of projects that have fallen by the wayside, failing to transform. This is the so-called “survivorship bias.” When we look at millionaires trying to uncover their secret to success — is it a money tree, a toad with a coin in its mouth, or a vision board?

Anyway, I’m going to deviate a bit from the standard “do this” approach and delve into more practical or philosophical questions about “what’s wrong.” But before we start, I’d like to share a bit about where I’ve managed to inflict some trauma on myself. As I mentioned, I’ve wandered through various companies and seen a lot of this and that, but EPAM has given me the most experience. Here, I had the opportunity to work with Fortune 500 companies, as well as on our internal product ecosystem, which includes over 100 large and small applications. Currently, I’m specifically focused on developing the user experience on Eduverse — our company’s educational product system, where people can teach, learn, test their knowledge, and discover new talents within themselves.

Now that you’re up to speed, I present to you my 10 physical and psychological traumas.

1. Lone Wolf Syndrome

If you think that after reading a dozen books on the product approach and getting fully pumped up, you can just kick down the door and the whole team will reverently follow your otherworldly wisdom, I have bad news for you. Nobody likes a know-it-all. If the team isn’t ready to accept the new rules of the game, they won’t play by them.

I joined my current project just as our new account manager was trying to shift things onto a product track, following all (or almost all) of the aforementioned commandments. I think he was really cool, but the team had been working with a project approach for 10 years, so they pushed back on absolutely every initiative. Eventually, the work just ground to a halt when the Account and Product teams got locked in a fierce deadlock. And nothing was getting done at all. Nobody likes it when Mom and Dad fight.

Watching the team go rogue, I thought this could have been avoided by using two strategies, depending on where you are in the food chain. Instead of kicking down doors and imposing your own rules, you can start the implementation with influencers — people who have some sway in decision-making. You can go top-down, securing the support of top management, or bottom-up, paving your way through misunderstanding by winning the hearts of your colleagues — developers, analysts, and designers. By the way, it’s worth starting with the latter, because they’re always hungry for a new adventure.

But whichever strategy you choose, or even both, everything will depend on how well you can explain and demonstrate the value of transitioning to product development to your counterparts. If your sleepless nights of independently setting up analytics or generating hypotheses pay off, you’ll earn trust on which you can then build a vision and strategy. Without team cohesion, it’s impossible to achieve this in any way.

2. Forgotten Users

One September evening, I learned of news that shook me to my core: the infamous Sony spent $200,000,000 and 8 years developing the game Concord, only to shut it down 11 days after launch. Just think about it: 8 years and 200 million… 11 days. There are many conspiracy theories and analyst breakdowns about why the game failed, but I believe the main blunder was that they spent 8 years building something without even asking the players if they wanted it.

You might think, “Damn, how could they screw up so badly?!”, but don’t be too quick to judge. In our world, driven by business, money, and metrics, it’s very easy to forget what we (I mean designers) originally worked for — to make the user experience as convenient and enjoyable as possible.

I believe there’s too much business in modern development. The classic love triangle of “Business — User — Technology” is no longer equilateral. More and more designers are replacing the word “Experience” with “Product” in their resumes and getting a 20% salary bump for doing the same work. You’re welcome for the tip. But this situation is increasingly encouraging designers to cozy up to product managers, taking on some of their responsibilities and paying less attention to their original purpose. It’s not surprising, since the client pays us, not the user. So, first and foremost, we have to please them so that other clients will come to us for help.

But here’s what I’ll tell you: good metrics ≠ good UX. Let’s keep business in sight and help products do their job, but let’s focus on what we do best — designing experiences. Besides us, there’s simply no one to protect the interests of the poor user.

3. It’s All Just a Step

We all know that a product vision is the driving force behind its development. Without a vision, we wouldn’t know where to focus our efforts, and the product would likely resemble an irregularly shaped bubble, torn in all directions before its swift and inevitable demise. But let’s be honest, even those lucky ones whose vision wasn’t created just for show don’t consult it every day.

It reminds me of how designers work with artifacts — they put them on a shelf, in a portfolio, and that’s it. No practical use. But it’s not the same with a vision, right? Well, do you want the truth or the ideal? You already know the ideal, so here’s the truth.

We know we should always keep the vision in mind, but knowing and doing are two different things. Building a vision and developing a strategy based on it is already a huge task. But it’s 1000 times harder to stick to the chosen course every time external circumstances do their best to derail you.

Sadly, instead of stable phases and milestones, strategy often becomes a plan that reduces everything to the familiar project approach. So we play at being product-oriented while still working on a project. And when something doesn’t go according to plan, we start panicking and minimizing risks instead of adapting our strategy.

I have a great example: I bet almost everyone reading this has cursed the creators of USB at least once while trying to blindly plug a flash drive into a TV or the back of a PC. And you probably thought, why not just make it USB-C from the start? Well, it was originally like that, but it was too expensive, making negotiations with all stakeholders difficult. And to reach a common standard, your nerves had to be sacrificed. It was just a step.

The vision should guide you, and what’s happening at this moment is just a step in that direction. In the past, like a pimple-faced maximalist, I’d scream my head off defending any, even the smallest, change in my decisions. As if someone’s life depended on it. But over time, I realized that compromises can be made if you see where you’re going. Yes, today, instead of a complete overhaul of the main part of your product, you’re only upgrading the typography. But this lays the foundation for future changes that will be easier to implement. Take conflicts more lightly when someone argues with your decision — it’s just a step. The main thing is that it’s a step in the right direction.

In this sense, I really like how one of our managers, Mr. Sh., handles any conflict, even the most heated ones. While everyone is arguing about whether to use cards or a list for our catalog, he seems indifferent, agreeing to everything. Because in his mind, there’s no catalog anymore, and course selection is done by an AI agent.

Evolution allows us to improve what exists but doesn’t allow us to create something new. That’s where revolution is needed.

4. Value Freedom of Thought, But Don’t Fall in Love with Solutions

How often has everything gone exactly according to your plan? I bet it hasn’t happened often, if at all. That’s why we need to get used to the idea that not all of our ideas are product revelations. We shouldn’t fall in love with them prematurely.

Personally, I always considered myself the kindest, gentlest, and most understanding leader in the world. However, one fine day, near the water cooler, I heard rumors that I was actually a tyrannical micromanager in the team, suppressing initiative and guarding my decisions like Cerberus. I tried to do everything myself, and deep down, I saw other people as a hindrance. These words stuck with me for a long time, so I decided to change.

It’s important to understand that you have a team for a reason. There are probably people on it who can do some things better than you. As difficult as it may be to accept, you’ll gain much more if you learn to trust your team.

Instead of providing detailed solutions and constantly checking progress, focus on describing the desired outcome or the problem. Give the team the opportunity to decide for themselves how to achieve the goal. Experiment. If you’re not satisfied with the result, you can always adjust the direction with quick and frequent feedback.

In our practice, this translates into conceptual design. We meet with stakeholders every day, involving them in decision-making and shortening the iteration cycle. At the same time, as designers, we’re not limited in how we solve the problems presented to us. In sessions, we only present the result. We can spend weeks discussing ideas that are never meant to see the light of day. And that’s okay. Freedom of thought is more important than any financial considerations.

Frankly, not everyone likes this pace of work, because the iterations are intentionally short so that we don’t have time to fall in love with a solution and then have to break and bend it until it works.

5. Nobody goes All-in

Another reason why implementing a product approach can stall is team apathy. Oh, how often I’ve observed those vacant eyes staring into the depths of space during daily stand-ups. The team will do as they’re told because, frankly, they don’t care. They’ve forgotten what initiative even smells like. Maybe it’s because some tyrannical oppressor crushed it? I don’t know.

You might not have encountered this situation, as it’s more common in large teams where responsibility gets diluted among dozens of people. When working on a project, you simply can’t mess up because the responsibility lies with someone higher up, and they won’t criticize themselves. And teams aren’t willing to change this because… why shoot yourself in the foot?

When responsibility is blurred and no one gets blamed for failure, people don’t understand what makes a product successful. They become self-absorbed and don’t understand what others are doing, believing that only they are doing something valuable.

I’ve never worked in the game industry, but I can see a pattern — the best games are born not from big budgets but from the unstoppable enthusiasm of a handful of people. If you don’t believe me, I recommend checking out the books “Blood, Sweat, and Pixels” and “Press Reset,” which tell the stories of creating cult hits as well as unreleased games.

Of course, you can try to cure this with a system of harsh punishments, but that won’t help. Want people to realize the value of teamwork and responsibility for the outcome? Make them launch a product on their own. Believe me, it’s an unforgettable experience.

I personally decided that to call myself a product designer, I needed to launch a product. And I even launched two: one is a service for unmoderated tests, and the second is my personal hobby. And very soon, when my area of responsibility was behind me, prototypes were made, tests were conducted, I realized that no matter how incredible the product I created, no one would use it because no one could find it, it was full of bugs, and it was time to shut it down due to lack of budget. And there was no trace left of my designer arrogance.

6. Ideas Are Worthless, Take Action

Before we move on, let me ask you a simple question: if I asked you right now to pull $1.65 billion out of your pocket and invest it in my idea, with a return on investment in 10 years but no guarantees, would you do it? I wouldn’t, even if I had a billion. I think such a question would make you blurt out “no” without hesitation. It turns out that you, like me, would have missed out on a great investment opportunity, because that’s exactly how YouTube was acquired.

Of course, now that everyone knows how it all turned out, it’s no surprise that it was a great deal. But back in 2006, when Google shelled out the cash, it all looked doubtful — YouTube was a rather immature platform with uncertain prospects, and all the economic experts agreed that the costs would far outweigh the profits, meaning Google would have to artificially keep the service alive. But we know how it all turned out.

What am I getting at with these questions? We often spend too much time refining an idea instead of just doing it and seeing how it works. Remember the case from my first “trauma,” where a manager was trying to impose a product approach on a bunch of traditionalists? Well, one of the innovations he brought was calculating the economics for each intake. Yes, it might seem like a good thing, but when you work in B2B or in an internal ecosystem like ours, the calculator can’t keep up. You can’t calculate ROI because profit isn’t generated — the budget is simply allocated, but no one pays to replenish it. And if there’s no ROI, you can’t tie value to money. As a result, we did NOTHING during that time.

It was only when we started thinking about the subjective value we would bring, instead of money, that we were able to do something useful. And later, these efforts were recognized at the Brandon Hall Awards. Here’s a controversial statement: you don’t necessarily need the numbers to add up if the idea really excites you. Try using your product yourself, feel how it works, and you’ll understand better what to do with it than by staring at spreadsheets.

Once, I was watching an interview with a high-ranking product designer where he shared his idea of creating a service for finding a therapist. He really liked the idea, but the economics just didn’t add up, so he didn’t start implementing it. And a year later, the “Yasno” service for finding therapists appeared, and apparently, everything adds up for them.

The moral: calculate the economics as much as you can, but don’t forget to actually do something. Even if the window of opportunity isn’t open right now, put a stool next to it so that when it swings open, you can jump right in.

7. Ugly Does (Not) Sell

Usually, people who become designers have a heightened sense of beauty: attention to detail, an obsession with structure, and a perpetual dissatisfaction with the result, with a touch of being a bit of a stickler. We can get triggered by things that seem normal to anyone else — a slight misalignment of text in outdoor advertising, an illegible font, or a silly metaphor. And when we work on a product, we always try to make it better not only in terms of usability but also in terms of visual appeal. However, sometimes this desire can contradict the result.

Back in the distant 2000s, I heard a very telling story from my colleague. He once had the opportunity to work with a window manufacturing company. They needed a beautiful new website that would drive sales. So my friend, rolling up his sleeves, put all his style and skills into the work, which immediately won the approval of the stakeholders. However, after the website was launched, sales plummeted. Why? Because the main customers for windows were elderly people who, looking at the new shiny website, thought that everything there was “for the rich” and went to ugly but cheap competitors.

Understand the context in which the product operates: maybe it doesn’t need to be beautiful, but rather cheap. Personally, it’s hard for me to accept that Amazon is the benchmark for product-orientedness, even though it frankly looks like a hot mess. The same can be said, by the way, about the top product from Kazakhstan — Kolesa.kz. It works very well, but my designer soul aches and howls. But my bulging eyes remind me that under the hood, everything can be much more complex.

8. When in Doubt, Test it Out

As I mentioned earlier, changing the style alone rarely brings benefits, just like any other idea, if it’s not thoroughly tested. Arguing about the benefits of testing and prototyping is pointless; their essence lies in identifying bad ideas for implementation to avoid wasting time and money, and confirming good ones. But why do we test so little?

This is a particularly sore subject for me because one of the products I’m working on that’s dear to my heart is Display, a tool that allows for unmoderated testing of prototypes and, soon, live websites. This is where I got one of the “scars” I described earlier. In terms of functionality, Display is no worse than its competitors and offers everything for free, but unfortunately, designers within EPAM test catastrophically little. And we’ve tried everything to change this: demo sessions, training courses, articles, workshops. But I constantly hear “clients don’t have the money,” “we have nothing to test,” “maybe later.” I have a theory.

Designers, like all people, I suppose, don’t like receiving feedback because they’re afraid to find out they’ve made something crappy, which means they themselves are crappy. Our profession is already one of the most stressful, where everyone around tries to give helpful advice by channeling their inner designer: product people say it’s not what they envisioned; BAs say it doesn’t meet business requirements; developers claim it can’t be done that way. Who in their right mind would want even more of that? Especially since if no one has any questions, and I bring bad feedback, it’s like I’m the one who messed everything up. No way!

But we have to put ourselves out there if we want things to work out. Somehow, we need to stop associating ourselves with our work and fall in love with testing, even though it can be incredibly difficult: who enjoys hearing some random user who doesn’t understand your genius tear your precious work to shreds? Instead, I’d urge us all to view such feedback not as a personal attack but as an opportunity to make the product better. Moreover, sometimes this tool can work in the opposite direction.

Here’s a recent example. We recently decided to test a style change for one of our products. We simply changed the style on one of the main screens of the application and ran a quick preference test to see which style people liked better: the old one or the new one. Literally the next day, my manager called me and asked if I’d seen the session recordings that had come in. I said I hadn’t had a chance yet, so he shared his screen with me, found the right session, and played the video.

On the screen, a young woman was moving her mouse from one option to the other, commenting that she didn’t know what to do. Suddenly, a guy’s voice, probably a colleague, came to her rescue:

— What don’t you understand? You need to choose either the left or the right option.

— Oh. So which one should I choose?

— It doesn’t matter, they’re both crap. Just pick one.

After the recording ended, the manager suggested I watch it again. And again. After that, it apparently became clear to him, as it did to me, that visual changes alone wouldn’t be of any use, and we needed to change the flow as well.

9. Obsession with Numbers

Oh, this is my favorite. How much products love numbers! Everything is plastered with metrics, and until the calculations add up, no one dares to press a key. How else can we measure results and output? If a user even thinks about not using a feature, it’s immediately cut and sent straight to hell! Every click, movement, sneeze, and fart is recorded and meticulously analyzed, because how else can we make decisions? Everyone talks about this approach, and I’m sick of hearing about it.

Honestly, it all reminds me of behaviorism. Those guys with white beards also used to say that if you gave them a newborn baby, they could turn it into anything they wanted. It all seems arrogant and foolish now, so why do we think that there’s some kind of code, key, or map to untold riches hidden in massive amounts of data? We confine the success of an entire product to the shackles of a few numbers, which become its judge and jury.

But here’s the problem with that — introducing any evaluation model into a system distorts the system itself. We don’t have to look far for an example, as our education system has taken care of everything. We need a method for assessing students’ knowledge because it’s important for us to understand how they’ve absorbed the material. However, the introduction of a grading system has led to a number of changes within education itself. Teachers don’t teach children to apply knowledge in the real world, but instead, they train them to get good grades. As a result, children can’t open a jar of pickles, but they’re awesome at acing tests. Teachers are happy — academic performance is excellent. Principals praise them at meetings and allocate a bigger budget for the next year.

In pursuit of good metrics, we miss out on a good product.

The quiz continues: would you like your company to switch to data-driven marketing decisions based on data you collect from your users, like Nike? We love to cite industry giants as examples. But this time it’s a negative one — follow the hype and lose $25 billion in four years. Just like Nike did.

Without going into the details of the case, the money went down the drain because Nike followed the “less effective but easier to measure” approach. In other words, they spent too much effort measuring the behavior of existing customers instead of understanding potential ones because existing ones are easier to measure. As a result, Nike tailored its marketing campaigns to those who were already on board — loyal customers, while fresh blood was never attracted. Oh no, I’m not suggesting that we shouldn’t measure anything. On the contrary, data plays a huge role in decision-making. But only if you know what data you need, not just what’s readily available.

I think there will be more and more cases like Nike’s, even if not all of them are made public. I’ve seen enough to have a clear imprint of skepticism about working with data in my mind. Don’t blindly trust the numbers.

10. Existential Crisis

And we’ve arrived at the most interesting question — does the product approach always work? I won’t keep you in suspense — not always. I’d even say that you’ll almost never encounter it in its pure form. There will always be something distorted, something missing, and something not working as intended.

But here’s an even more interesting question (get your tomatoes ready): do we even need a Product mindset to create good products?

Actually, good products can be launched without it. Whoa-whoa-whoa, put down the tomatoes. I said it’s possible to launch, but with product thinking, you significantly increase the probability of a positive outcome for your venture. Nevertheless, this is an advanced task.

Sorry for another example from game development, but I’m apparently heavily influenced by the literature I read. So, most AAA games are projects. Of course, modern game development has adopted many practices from the product approach, but AAA games are still projects. And I don’t think this fact will make us love RDR2 or God of War any less.

The product approach is needed to create products, it’s right there in the name. If you try to apply it in an unsuitable context, it might not fit. For example, if we take our approach out of the cozy world of B2C and into the bloody reality of internal platforms… nothing will happen.

We’ve built a vision and strategy, we’re concerned about metrics, but… Our satisfaction score was already 4.8/5, which meant our product was almost at the peak of awesomeness. The problem is that users don’t pay us. Frankly, they have no choice — they’re forced to use our products, so whether we deliver value or not, they don’t care. But we still continue to care about our users, even though they don’t give a damn. In our situation, all the classic metrics simply lose their meaning because we own 100% of the market. There’s no competition because migrating such a behemoth to another vendor’s platform is economic suicide.

It seems like everything’s great — just work and don’t worry. But there’s another, slightly more global problem. Our platform consists of more than 100 products, big and small, each of which adheres to the product approach. Each is created to perform specific functions. And functions tend to end, while the product approach doesn’t imply a final completion date. When the resource is exhausted, but no one wants to die, all these project-like products start fighting for their place in the sun, pulling in more and more business cases. As a result, all applications in the system grow unnaturally, increasing complexity that doesn’t benefit the user. So it turns out that the product approach is actually harmful.

Products should be developed with a product approach, and projects should remain projects. Only then will the delicate balance of the universe, your mental state, and the company’s budget be preserved.

In Conclusion

Honestly, I’m not sure how valuable my work on this article is in terms of implementing product methodology, as I’m not a seasoned product manager. However, I’ll be incredibly happy if my thoughts inspire someone to take action, and that helps make someone’s life better. Or, at the very least, you can avoid a couple of pitfalls that have tripped up more than one product manager. Thanks for reading to the end, I sincerely appreciate it.

Sources

1. Nike and their data fail
2. Why Sony Concord failed