Anti-patterns: 8 Things Not to Do in Your Quest to Build a Great Product

To maximize your chances for success, there are anti-patterns to watch out for, and dark waters you don’t want to enter. Below, we explore what to avoid when building a product, from neglecting your product strategy to not considering the problem-solution fit.

For Product Managers (PMs), building the great product is like navigating a ship towards treasure. It’s a long journey, but success is somewhere ahead, and it’s up to you to lead your team to it. You’re the captain, you have the best people on board, and your ship has top-notch equipment to lead you wherever you want to go. Your Holy Grail is just behind the horizon. Why worry?

You’ve heard about hidden rocks that may damage your ship, storms that might occur unexpectedly, and vortexes that can soak the whole vessel. But nothing bad has happened so far; every crew member is busy, and the ship seems to be moving in the right direction. Maybe there’s no need to worry?

You wish.

Enter anti-patterns, a common response to a recurring problem that’s not only unsuccessful, but risks being counterproductive.

Coined back in 1995 by Computer Programmer Andrew Koenig, and inspired by the book Design Patterns, anti-patterns refer to a “solution” that despite initially appearing appropriate and effective, ends up having more bad consequences than good ones. In fact, another solution exists that’s documented, repeatable, and proven to work.

Below, we outline anti-patterns that can mess with your product development process, affecting the end result, its robustness, and effectiveness. Read on for the list of product DON'Ts – bad practices to avoid. We’ll guide you on best practices in the next article from our anti-patterns series – so stay tuned!

1. Not caring about product strategy

Why should you think about something as high-level as business goals and strategy when you’re building a product? You have features to be delivered and should focus solely on those. Maybe you’ll explore problems to solve and business impact after the next major release. Actually, you prepared a document a while back about how your product will make money and add value, but you haven't really looked at it since then – or shared it with anyone.

2. Not involving your product team regarding the “why”

Why involve your team in anything more than their individual tasks? They already complain about having too much on their plates, so well-described requirements and Jira tickets should suffice.

Because sprints are always full and deadlines are tight, it’s better to let the team focus, rather than involving them in discussions about problems, purpose, and why they’re building the product in question.

What about other teams? You’ll let them know in due course, when you’re a bit less busy.

3. Neglecting to think about the problem-solution fit

You have a product roadmap and release plan approved by C-levels, including stakeholders’ feature requests. It was tough going, but you’ve managed to pack everything in. There wasn’t any time left for buzzwords like “problem”, “validation” or “unique value proposition”. Data to prove roadmap items can always be found later on, if anyone asks.

4. Not creating product metrics before launch

Planning how to measure whether you’re on the right track – who bothers with that, let alone involving the whole team? Features delivered on time are the best measure, and if anyone asks, you can always add KPIs after release.

5. Not interacting with users – product discovery is just a fancy buzzword

Interacting with users yourself? No way – that’s for PMs with more time. Anyway, you already know what users think – you received feedback from the Support Team outlining product issues. Why should you care how many users are affected or whether the product solves users’ problems? Even the CEO had a try and was pleased.

6. Disregarding product cost because “so much” work has already been done

So much work, time, and money has been spent on delivering certain features, and expectations are high throughout the organization. It’d be a waste not to finish, so let’s carry on.

7. Focusing solely on the digital product purpose. Isn’t the rest obvious?

As a Product Manager of a digital product, you care about releases, features, APIs, and bugs – that’s already more than enough. If users don’t know how to use the product, or it’s possible to solve a problem in a non-digital way - who has time to dig into that, especially if the feature machine is already rolling?

8. Acting as if your product manager role is “Jack of all trades”

It’s your job to get involved in any issue connected to your product, because you’re the face of your product and the first point of contact for any matter related to it. You’re invited to so many meetings and are needed everywhere, so there’s no time to think about problems, strategies and validations.

Obviously, the above points aren’t good product patterns to follow. Exaggerated? Yes. But they do happen to varying degrees. Falling foul of one or more of these anti-patterns increases the chance of product failure, so it’s vital you’re aware of them.

Business consequences of product anti-patterns

Anti-patterns can be found in any organization following bad practices. Sometimes, companies fall into anti-patterns without realizing it. But the worst instances are when organizations follow anti-patterns intentionally – for example, when they know a product is harmful, yet they still sell it, or are aware of critical bugs and go ahead regardless with a product release, to meet a deadline set by a CEO. We like to call that “getting into the vortex”.

Take a look at the following, for additional proof of how dangerous intentional anti-patterns are:

• Volkswagen’s emissions scandal
• Ryanair’s hidden costs
• Facebook knowing that Instagram is toxic for teen girls

These examples put company reputations at risk and are proof that even big and well-known enterprises don’t always manage to avoid anti-patterns.

You never want to be in that position with a product.

Three stages of a product anti-pattern

To avoid falling into an anti-pattern trap, keep the following three anti-pattern phases in mind:

• First signals. An anti-pattern is on the horizon – it’s not happening yet, but first signals are visible (examples are highlighted in the next section).
• Actually happening. If you find yourself in an anti-pattern like micro-managing or not involving your product team in the “why”, act quickly to rectify.
• Vortex. An anti-pattern is in full swing, such as forging ahead with a new product or feature despite ethical concerns, or the “getting into the vortex” examples outlined in the previous section.

First signals

By detecting anti-pattern potential at the “first signals” stage, it’s possible to take action and prevent the anti-pattern from becoming a reality, increasing the chance of a product’s success.

If you’re a decision-maker, be vigilant if you spot any of the following:

• Product team and/or product manager doesn’t know why they’re doing what they’re doing, or team members give varying answers
• Product team and/or PM is unable to say who the customer or target audience is
• Product team complains about being overloaded with work, yet no one knows what’s important for the end-user
• Nobody interacts with end-users (except for the Support Team reacting largely for users’ complaints)
• No end-to-end testing
• Zero quality assurance (QA) processes
• Massive pressure on deadlines versus quality
• “Let’s release and fix later” approach
• No checking of legal and regulatory compliance and privacy practices.

Anti-patterns: Hungry for more?

This article is just the beginning, introducing a series of posts where we cover each of the eight anti-patterns in greater detail. On top of that, Netguru Product Managers share their experiences and offer advice on how to spot and avoid anti-patterns, and tackle them if they do happen to occur. As a result, the end product is more effective and business performance improves.

Next article of the series is coming out soon.