Skip to main content

Select your location

Search
Two women looking at code on desktop

The 10 biggest misconceptions about building software products (and what you can do about them)
 

Users need connected, accessible and adaptable products that make their lives easier, which means they need the organizations behind them to be connected, accessible and adaptable, too.

As a product strategist, I work with a variety of clients to not only evolve their product strategy but to mature their product development execution and processes. I am not a consultant who “whooshes'' through the business, drops a recommendation report, and says goodbye.

No, I roll up my sleeves, integrate into teams at large enterprises, look for ways to help them progress their thinking, and act as a transformation partner and enabler to help build digital products and experiences that are invaluable and evolving assets for organizations.

Having worked across many industries, companies, and teams I’ve gained a perspective that individual enterprise leaders aren’t necessarily able to achieve. Over the years, I’ve experienced several common pitfalls and obstacles that have challenged my clients, and helped craft various solutions that fit each situation.

Here I will share with you the top ten misconceptions about product development that [X have] along with ways to get on the right track.

Now before we dive in, I am not suggesting that you should throw out the process you’ve been following for years and try to stand up a brand new process overnight. My intent is to offer food for thought by shedding light on some of the biggest traps I have seen enterprises fall into when attempting to build better software products. Consider the points I’ve listed, and consider using these to challenge “the way things have always been done.”

The misconceptions on this list, or some version of them, may be “sacred cows” in your organization. I urge you — go cow-tipping. Disturb these sacred cows so you can achieve better product agility and drive more positive impacts for your customers in the products you release to the market.

Misconception #1: Product development is owned by [insert name of department here].

Product development is not a discrete function that slots into one particular department. There is not a single owner. Rather it is a collaborative function that spans several departments and is “co-owned.”

Commonly, departments involved in product development include IT, the business line, and engineering. Skill sets that contribute to the process include business analysis, user experience, architecture, and project management.

Key points to bust this misconception:

  • Building world-class products involves connecting multiple departments and cannot just be driven by one.
  • Shared ownership and collaboration are key.
  • Product development team members need to understand and collaborate with the domains involved in the process but do not need to own them.

Misconception #2: IT and business departments have to combine to form one department.

Tearing down silos to build a broader cross-functional department that includes both business and IT members, would be ideal. However, this is not a possibility for the vast majority of enterprises.

Even if it could be achieved, it still wouldn’t optimize product development. Other departments are often involved with design and research, or some members of the development team report to other managers. There is just no practical way to put product development in one mega-department.

Key points to bust this misconception:

  • Break down silos by creating a cross-functional team structure that includes IT, business, and other departments as stakeholders.
  • Form a tribal “pod” that includes all the necessary roles to build great software. For example, include product owners, user experience designers, user experience researchers, scrum masters, architects, developers, and quality assurance testers.
  • Empower this team to really own the product. Let the members make decisions--from day-to-day design decisions all the way up through the roadmap and the product vision. Senior leadership’s role is to provide oversight and to ensure that results are aligned with the business. This gives your team tremendous freedom, allowing them to move fast while baking customer value and business value into the product you build.

Misconception #3: Once they get going, the team will take care of itself.

Another way to say this is, “We don’t need to check in on our teams --they’re morale is fine.” Yes, your product development team needs to be self-driving, making decisions themselves. This doesn’t mean, however, that you can just wind them up and turn them loose while you turn attention to other things. Things may seem to be going well, but how do you know for sure if you’re not interacting with them?

Key points to bust this misconception:

  • A quick and easy way to bust this misconception is to send out a weekly survey. Make it no more than three questions, so it should take 5 minutes to answer and send back. Reading the results lets you to spot check team morale while giving the team a chance to raise concerns or blockers and to take ownership of the product.
  • Keep in mind: Happy teams make great products. Great products make happy users. Happy users make achieving product and business objectives possible. 

Misconception #4: Product managers are the CEO of the team.

Hierarchy is not effective on a product development team. You want everyone involved to take ownership of the product. That means they will feel more comfortable making enhancement suggestions that could positively impact the team, the user, the product, and/or the business. Win win win.

Key points to bust this misconception:

  • Remember that empowered teams build better products.
  • Think of the product manager as the chief connector. Their job is not to dictate requirements and tell people how to do their job. It is to be the bridge to all functions, communicate the why, and ensure team members are aligned on solving problems and achieving organizational goals (in the context of your product).

Misconception #5: The product development team must always be working on new features. 

This way of thinking risks creating feature or delivery teams that just churn out a predefined backlog of work that has been prioritized by someone else who didn’t consider customer feedback in the solutions or in the prioritization.

It’s much more important to be agile in the research and design phase, taking customer preferences into account, to ensure that the first real product that a user interacts with truly addresses a customer need. The result: a Feature-Frankenstein’s monster application.

Key points to bust this misconception:

  • Run tests in pre-production. New features should only be considered for production development after it has been proven, to a certain degree of relative confidence, that they will provide value to your customers.
  • The development team needs to know the results of tests and experiments, good or bad, before starting work.
  • Give your teams problems to solve and trust that the solutions they come up with.

Misconception #6: The product roadmap should be built out for the next 1 to 5 years.

Write your plans in pencil and your goals in pen. If you absolutely have to plan for a year or more out, push for items on the roadmap to be framed as higher fidelity items like customer problems instead of solutions. Or initiatives or themes instead of features.

Key points to bust this misconception:

  • Review and change your goals on a longer time horizon and allow yourself to change your roadmap on a frequent basis.
  • Zoom in on work items. Let those plans change as needed and be owned by the teams that are doing the work.
  • Zoom out on strategic level goals and initiatives, plot those things on a roadmap with target dates and hold your teams accountable to getting something into the market that addresses/achieves those goals in the desired timeline.
  • Slow roll the releases of value if needed - the team should be able to make the call on what the solution will be for that goal (with intermittent checkpoints with you along the way) that addresses that goal.

Misconception #7: Talking to customers is expensive, takes forever, and/or scares us.

“What if they tell us the product sucks?” Well, good thing you found out your product sucks now and not later! Finding out something misses the mark earlier on in the product development lifecycle allows you to change your target sooner, thereby increasing your speed to the right solution.

Key points to bust this misconception:

  • What is more expensive: talking to customers before building to understand which problems to prioritize or spending weeks/months building then launching it to the market and it not being used?
  • Invest in talking to customers early with the aim of de-risking your value hypothesis.

Misconception #8: Project management is the same as product management.

Project management is anchored in time and has a specific end result. Product development is open-ended timewise and may evolve as user needs change. Product development may comprise projects to be managed at points along the cycle, so one is sort of a subset of the other.

Key points to bust this misconception:

  • Shifting the focus from the project to the product allows team members to be singularly focused on the what, the why, and who the product is for.
  • Continuous improvements is imperative.

Misconception #9: Once a feature is released our job is done.

“Let’s get this feature out the door, order pizza to celebrate, and move onto the next item in our backlog.” Releasing something into the product is just the beginning.

You did all this work to minimize the possibility of releasing something that customers dislike. But, since change is constant, you still cannot know for sure how markets will react to something. Your job is not done, though the work may shift from being proactive to being reactive.

Key points to bust this misconception:

  • After releasing something, do celebrate that accomplishment and all the work it took to get to that point. But temper that with the reality that you now have to switch gears a bit. Monitoring how something performs, post-launch is a great way to uncover future enhancements that can be made to a product.
  • Involve product marketing in the process way before your product or feature is released to the market. Allow them to ideate and plan alongside product development. Doing so will ensure they create the best product they can --great marketing strategies, campaigns, and content.
  • Think about a feature as a test. Test and learn. What will you hear back about what you just put into the market? How could it be enhanced? Ask customers about new features as well as features you have planned for the future.

Misconception #10: [Insert new technology here] will solve all our customer’s problems!

A new cutting edge technology does not automatically solve your customers’ problems. It is a tool in your toolbox to be harnessed in order to create moments of delight.

Key points to bust this misconception:

  • End-user problems need to be central to the tooling your organization selects, yes, but those tools alone don’t solve the target customer problem.
  • Test and learn. Iterate your way to success. If you are considering rolling out a new tool, component, or piece of functionality, test it in a cheap, quick way if you can, ideally with a group of the target end-users.

Product development teams that believe these misconceptions do not build customer-centric products and are unable to move quickly. Organizations that believe these misconceptions also are unable to respond to macro changes as quickly as is needed.

Take the COVID-19 pandemic for example —your teams need to be structured in such a way that they can respond to changes in customer behavior quickly. Digital-first and agile-first product teams weathered the impacts to their businesses better than teams that still adhere to digital-second ways of thinking.

If any of these misconceptions about building better products feel familiar to you, it might be time to start rethinking how you, your team, or your organization approach product development.

If you think you may need help in your digital transformation journey, don’t hesitate to start a conversation with Kin + Carta today.

Contact us here

More like this