2 Deadly Sins of Product Development

When a company is developing a new product, or a new set of features, there are a number of areas where the project can fall apart. The two we're covering today represent the two biggest problems we've addressed to help companies stay on or ahead of budget, produce a deliverable on schedule, and gain traction with consumers.

1. Caring Too Much About the Idea

The Problem: There's a big different between being passionate about the idea, versus being passionate about serving your customers. Most companies we work with face budget constraints, an ever-growing to-do list, and what seems like a never-ending support cycle for every product they release.

In talking with them, the problem isn't so much centered around procrastination, nor does it have anything to do with their people not taking pride in the brand. In fact, these days, we often see the exact opposite. Enough has been said in the past 10 years about the importance of culture, employee engagement, and the Jim Collins bus metaphor (getting the right people on the bus) has been beaten to death. To be clear: I'm a huge fan of strong, ever-evolving corporate cultures centered around service, quality, and constant improvement. What I'm not a fan of is the phenomenon we're seeing over and over again: Teams that are too stuck on the original idea, rather than listening to what their customers are telling them.

Now, I have yet to encounter an organization with majority awareness that they too have this “blinded by romance” bottleneck when it comes to improving product-market fit. It normally takes someone from the outside to show them that – despite their intentions – they have lost sight of their customers' needs and desires that are both relevant today, and for the foreseeable future. Metaphorically, they are going to where the puck is, rather than where it's going, thus putting them consistently behind market demand.

The Solution: When developing a product or service, step into the psychology – the way of being – of your customers and target market. Could they see your idea and immediately want to pay for it? If not, there is a disconnect between your version of the idea, and the market you're serving. To get around this, bring on a team of early adopters for your product. In software, this would be beta testers. In pure product or service models, you'll want to compile a team of consumers from your market, and tell them they will be in integral part both in market research and in helping the idea come to life.

In other words, caring too much about the idea typically leads to people guarding their idea from the outside world, and often closes them off to ideas that they believe will “taint” the original idea.

Instead, build customer feedback directly into the development process, allowing you to secure pre-sales (immediate cash-flow), produce something of high quality by the market's definition rather than your own (product-market fit), and this, almost always, leads to an earlier release date – as you end up avoiding the “perfectionist / paralysis by analysis” phenomenon.

This leads us to problem #2.

2. Waiting to “Release the Masterpiece,” rather than One Piece at a Time

Small batch size is the key to a product development team's success. Your customers want solutions as close to real-time as possible, upper managers want to be effective and have their work result in increased earnings for the business, and development teams constantly crave new challenges and derive fulfillment from successful product launches.

One way to look at small batch size is to first examine the antithesis, which is surprisingly common in small and mid-sized companies. Most development teams get stuck in the following statements / ways of thinking:

• “We'll be able to launch the product just as soon as we add feature X”

• “Our competitors have A, B, and C, so we need our version to have A, B, and C.”

• “X is taking longer than expected.”

• Any use of the term “finished product.”

The reason these ways of thinking are often problematic have to do with the fact that they all delay when you can start collecting payments for something you're developing. More importantly, however, is the delaying of customer feedback, which is actually more valuable to your business long-term. Even if your product isn't a one-time purchase, the feedback that comes from customers will outlast the money you collect from those customers 80% of the time. If you're not looking at customer feedback as currency for your business, then you're likely missing insights as to where the market is growing, how its demands and needs are changing, and where the consumer's money will be spent in the future – leading your teams to be reactive rather than proactive and, ultimately, causing you a lot of pain down the road.

Small batch size means you quicken your output of deliverables by breaking down the “full product” into smaller pieces. In lean, we call this releasing the minimum viable product (MVP). As your MVP is out in the market, and customer feedback is driving the continuation of internal development, product updates, added features, fixes, etc., you are working toward your MaxVP, or maximum viable product – a product that is finely tuned to the customers' needs, with an acceptable amount of market acceptance to produce positive ROI (vague language because “acceptable” varies from business to business, and product to product...even person to person) and that is robust enough to be a mostly passive income stream for your business.

Common Criticisms:

• “This sounds great for a start-up, by my business is different.” → I know we all want to think of our respective businesses as snowflakes (especially true for anyone who describes their business as a “lifestyle business”) but the truth is swapping out old ways of internal development for iterative (basically meaning constantly revised, improved, and built upon) processes that are formed over time through direct customer/user input is really the only way forward in this new economy. Furthermore, companies we've moved toward these types of processes have – quite literally – reduced wasted time and resources by upwards of 50%.

• “I've heard of things like this, but it's utopian. This wouldn't work in the real world.” → Most of this time this criticism comes because the perceived difficulty of change, and long-held anecdotal beliefs (typically referenced when someone talks about their years of experience) that seem to contradict this way of thinking and doing. Truth be told, many of today's business solutions are counter-intuitive and not-obvious. The best I can say to this is take a look at your own business. Think of the challenges you're having and if any of them would fall into the bucket of “resource allocation and management.” This way of doing things was developed out of necessity, because the pain of losing one's competitive advantage, and being stuck in a particular phase of growth (often due to a lack of internal resources) were overwhelming. If you can at all relate to these challenges, a solution like this is worth examining.

• “My people would never go for this. It's too big of a change.” → Poorly implemented, and you would be correct. The key here is translating this change to concrete reasons why this is good for your people from their point-of-view. Along the same line of thinking: Think of your employees as your “internal customers.” Your company has probably done some form of market research in the past to determine what customers will pay for. Take the time to do “market research” for your internal customers, and ask them if they would be open to this type of solution. What would they need to see to be okay transitioning to this way of doing work? Is there any reason they wouldn't do it? How can you, as a manager, best help them during this change? If they were in your shoes, how would they go about implementing something like this?

By no means is the above list of common objections and concerns a complete one. The purpose of this article is not to cover this topic A to Z, but instead open up a discussion around a “new” way of doing things. This method isn't actually new, the “proof of concept” has been established in a multitude of economies, companies, and industries. The teams we've worked with to implement these changes were all extremely apprehensive at first, but if you talk to them today, they would never go back to the old way of doing things.

As you give this discussion some thought, please let us know what you think in the comments section below, or drop us a line.

Originally posted on PerformanceBuilt.net