Breakthrough Insights

How to Build Products That Customers Love

Having the wrong tool can feel a lot like pounding a square peg in a round hole

One of the first questions I help prospective customers answer is this: Do you even need a tool to help with product definition, traceability to specifications, validation and verification? Over time, working with both prospective customers and customers alike, there are some common characteristics that can signify where Word and Excel documents will begin to breakdown, and not only insufficiently support your process, but actually slow you down, causing you to miss features, deadlines, and to ultimately end up over budget and miss out on market share.

Teams that typically need a tool express characteristics such as product complexity—building a product with embedded layers of software, hardware, firmware, and with multiple product variants; process complexity—teams responsible for designing and building each layer of the product have their own methodology (Agile vs. Waterfall vs. V-Model, etc.) and their own tools to support it; or organizational complexity—product, marketing and development teams distributed across multiple time zones, needing to keep everyone working off of the most up-to-date information. Regardless of where an organization falls, the goals typically remain the same: build a product representative of market demands, a product that customers will love, and a product that gets there before the competition does.

There is, however, a plot twist: teams can be terminally unique and will fight to protect their way of doing things. Teams can think their way is the best way, and do not want a process prescribed to them. However, this doesn’t change the fact that they are responsible for building a product that achieves their business objectives and need to maintain an ability to stay aligned and understand change while adhering to their own process.

In addition, the way people desire to work has changed. Folks new to the workforce expect a connected, collaborative tool.  It needs to look and feel a certain way—a database or repository can no longer look and act as such. It needs to flex and adapt.

Having taken all of this into consideration and determining that you need a tool, it comes down to picking the right tool. Often times that requires one that is configurable and meets the unique needs of your organization. Something we hear frequently from our customers is that they love Jama’s ability to adapt and configure to the way their teams work. Teams can’t afford to spend time trying to wedge their process into a prescriptive tool, one that tells them how they think they should work, one that excludes people from the definition and development process instead of bringing them in early and often. When considering a tool that helps you meet your business and product delivery objectives, I hope you consider a tool like Jama that can flex to fit the way your teams want to work, one that can help you meet your goals for building great products that people love.