Tag Archive for: product delivery

With ever-looming deadlines and high expectations, it’s possible that software developers at some point in their careers will be subject to “crunch time” — weeks or even months of intense pressure that requires many extra hours to deliver a product on time.

These extended workdays, fueled by caffeine and cortisol, can wreak havoc on the health and mental well-being of those involved, and nobody does their best work under those conditions.

Product managers have a responsibility to their team members to plan and execute development projects in such a way that mitigates the need for such soul-crushing marathon sessions, and the successful delivery of a project may depend on taking those steps.

Failing to plan to avoid the need for crunch time can lead to team member flameout, and somewhat ironically, jeopardize a project’s timeline.

Planning and Communication Beforehand

Communication is a central component to fostering a development environment where developers’ resources are put to efficient use, limiting redundant efforts wherever possible and clearly enumerating every team member’s responsibilities.

Ernesto Mosquera, President at Global & Sustainable Products Consulting, emphasized this point in an interview, highlighting not only the importance of communication and planning in navigating a complex product development project, but also the key step of getting input from workers on the ground.

“For an on-time delivery it is essential that preliminary planning of the project is done in detail and involving all key resources,” Mosquera says. “In this phase, a realistic scope and timeline for the project is created that matches the requirements of the product management.

“My experience has shown me that if in this phase you do good and accurate work communicating with the team members and involving their input, you create the right foundation for a successful and on-time delivery.”

Staying on Track

Part of this involves setting realistic expectations from the outset and building in extra time for any complex development project that could result in excessive crunch time.

Establishing this time buffer allows team members to work at a sane, healthy pace, and can avoid last-minute time crunches that are all-too-often necessary elements of many development projects.

Of course, sometimes projects are thrown off track by unforeseen problems or changes. But the earlier and clearer those changes are communicated down the chain of command, the less likely they will lead to a potentially project-killing situation.

In these cases, using an effective product development platform that provides end-to-end traceability can also prove advantageous. With full traceability, teams can accurately assess the impact of changes up and downstream while making time to ensure full coverage for priorities and keeping everyone aligned throughout development.

Product Manager’s Responsibility

Lance Ellisor, Chief Growth Officer at Journyx, said he favors an approach where a product manager creates clarity and ruthlessly prioritizes throughout the process, which hedges against zero-hour panic and frustration as key team members realize they’ve been working from an out-of-date set of instructions.

“The product manager’s most important responsibility is to ensure utter clarity — of both scope and timing — between the stakeholders (customers/market) and the team delivering the work,” Ellisor writes in an email.

“Not only does this clarity avoid last-minute changes, it also optimizes project costs by frontloading any changes such that they have the least cost and the most impact on the project success.

“This means involving stakeholders (and the team) in clarifying needs, reviewing the proposed design, interacting with prototypes, test-driving the solution throughout as it’s being built, and affirming the candidates for release.”

Staying Afloat

The responsibility for building a foundation of clarity of purpose falls squarely on the product manager. Prioritization of project goals and deadlines must be understood and communicated to the stakeholders, and it’s not always an easy decision to make, according to Ellisor.

“The product manager must prioritize the needs with vigorous discipline, and frequently throughout the project as realities unfold and the time gets short,” Ellisor writes. “This is where a product manager quintessentially proves her mettle, as she’ll have to make some very tough tradeoff decisions — informed by both stakeholder needs and engineering constraints — to ensure a timely delivery of a solution that has the most value.

“It’s akin to having to throw some supplies off the boat in order to keep it from sinking; not a fun responsibility, but heroic.”

By meticulously planning each phase of a project, including budgeting time for the unexpected, and above all continuously communicating changes and expectations to your support staff, you can greatly reduce the odds of those long, miserable hours of crunch time.

Learn how to overcome more development challenges with our white paper, “Top Three Frustrations of Product Managers and Tips to Avoid Them.”

Today, most consumers research products online before purchasing. Doesn’t matter if the product is B2C or B2B, or even if there’s a single competitor in the marketplace. You can bet customers are searching for opinions on your product, as well as alternative options.

“We are seeing the growing power of a customer in driving perceptions of brands/products, and reviews is just one way,” Tom Collinger, Executive Director of the Spiegel Research Center at Northwestern University, wrote in an email to Jama Software.

Recent research has highlighted the ways in which consumers perceive online reviews and how they inform purchasing decisions. And from that has come insights into how companies can think about online reviews — including why negative ones aren’t all bad — as well as ideas for future-proofing from backlash.

Value of Online Reviews

Researchers at the Institute of Cognitive Neuroscience at University College London, for instance, recently looked at how online reviews influence the perception of a product. The study first had 18 participants rate a range of Amazon items based only on image and description. The subjects were then asked to score the products a second time, but were instead shown the image along with aggregated user reviews, which displayed the average score and total number of reviews.

Turns out the subjects’ opinions were very much swayed by reviews, as their second round of ratings fell somewhere between their original score and the average. As Science Daily notes, “Crucially, when products had a large number of reviewers, participants were more inclined to give ratings that lined up with the review score, particularly if they lacked confidence in their initial appraisals, while they were less influenced by ratings that came from a small number of reviewers.”

As the study showed, people leaned more toward group consensus when their confidence about a product’s overall quality was low and the pool of reviews was large. Anecdotally, this seems to track. If you see a product online with over a thousand five-star reviews versus one with just two five-star reviews, you’re probably more likely to trust the one with more reviews, since it appears more credible.

Importance of Average Scores

Not that products with tons of 5-star reviews receive a blanket pass. Another recent study on the power of online reviews, this time conducted by Northwestern University’s Spiegel Research Center, in conjunction with the platform PowerReviews, analyzed millions of customer experiences from online retailers.

Northwestern discovered that products with near perfect scores can sometimes appear almost too good to be true. “Across product categories, we found that purchase likelihood typically peaks at ratings in the 4.0 – 4.7 range, and then begins to decrease as ratings approach 5.0,” the report states. So while you shouldn’t seek to attract purely negative reviews, some can help your product’s authenticity.

Beyond that, Northwestern also detailed some other ways in which negative reviews can help a product. By displaying at least five reviews online, positive or negative, the purchase likelihood is 270% greater than that of a product with zero reviews, according to the study.

Importance of Early Reviews

The study also discovered that nearly all increases in purchase likelihood of a product from online reviews occurred within the initial 10 reviews posted, with the first half of those being the most influential.

Of course, not all websites display reviews the same way. Some sort by review quality over chronological order, for instance. For the purposes of this research, the first five were found to be the most important regardless of how they were presented. “Our analysis describes the first five the consumer sees,” Collinger wrote in an email to Jama Software. “This is independent of the way in which they are listed by the retailer.”

This is why it’s so important for a company to get a product right at release. If a new offering gets savaged by a wave of online reviews initially, regardless of how they’re sorted on a website, those will be the first and most influential opinions people read when considering a product. And that reputation can stick. Patching the problem in future releases well help, but then you’re counting on people updating their reviews later on, which is no sure thing.

Good Products Come From Good Processes

When managing online reviews, the Northwestern study urged companies to focus on the first five reviews, embrace critical reviews, and follow-up purchases via email to urge consumers to write reviews. In fact, reviews from actual, verified buyers — as opposed to those who post reviews anonymously — are more likely to be positive than negative. Also, making it easy for buyers to post reviews on a company’s website, for instance, regardless of their device or platform, was recommended.

From a business standpoint, one other fundamental way to get online reviews working in your favor is by releasing the best product possible. That starts with a solid development process, with plenty of quality safeguards in place.

Best practices like implementing test management early and often, for instance, will reduce the number of defects or bugs that are likely to show up in your final release. Often, it’s exactly those types of design misfires that’ll get a product maligned by early online reviews.

And while ensuring the quality of a final product is a key factor of success with online reviews, according to Collinger, it doesn’t stop there. “Getting the entire customer experience right is the very simple solution to leverage this growing customer influence,” he wrote.

Bridging the Gap in Digital Product Design

Digital technologies are converging with traditional products at dizzying speeds. This fast-paced, integrated evolution is changing product development, and many companies are struggling to retain their footing.

Despite the shifting landscape, one thing remains clear: an excellent product requires a solid development process. Helping companies improve product development is at the heart of what Jama Software does, but we know this complex practice extends far beyond our platform.

To get a better feel for the methodologies and pain-points teams are facing creating connected products, we sponsored a Harvard Business Review Analytic Services study. The resulting report, “Bridging The Gap In Digital Product Design,” features insights from nearly 300 innovators from a variety of industries, including manufacturing, technology, healthcare, financial services, and more.

What We Discovered

While we knew connected products were becoming more prevalent in our everyday lives, that trend has only just begun. A full 86% of organizations in our study have either applied digital technologies to their existing products or services, or are in the process of doing so.
86% of business and IT leaders are developing smart products or planning to
For many businesses, adding software to their physical products is already a challenging proposition. It’s compounded by stress from new competitors threatening disruption. To maintain an edge in this new reality, companies are being forced to act fast, and that’s placing significant strain on the development process.

In fact, 80% of those implementing digital technologies say they feel either somewhat or significantly added pressure to increase time to market for products and services. And an even greater majority (89%), expect that pressure to grow in the future. According to the report, some of the other big challenges businesses are facing with this transformation include ensuring new smart products work within the ecosystem of other connected devices, the clashing of traditional and digital product design, and trouble staffing and training the right employees.
89% of business and IT leaders expect somewhat or significant increases in time-to-market pressure from implementing digital technologies
When implementing any new process, there’s bound to be some unforeseen obstacles along the way. For instance, just 24% of respondents in the report identified the need to manage and secure customer data as a major challenge. The problem is many organizations may be underestimating this responsibility, according to Hans Brechbühl, executive director of the  Glassmeyer/McNamee Center for Digital Strategies at the Tuck School of Business at Dartmouth, who was interviewed for the report. That’s because while the constant flow of usage data can be advantageous for informing future product iterations, companies inexperienced in managing this information may not realize the evident risks.

What’s Next

There are so many valuable insights and trends within “Bridging The Gap In Digital Product Design” it’s more than will can fit into a single post. That’s why we’ll be diving deeper into some of the themes and findings in the coming weeks with a dedicated blog series, featuring observations from Jama Software experts.

And let me know any feedback or questions in the comments below. With so many major industries refreshing product offerings with connected devices, the conversation about the best methodologies for improving and maintaining this process is just getting underway.

40-50%. That’s the percentage of companies that manage the creation, iteration, testing and launch of new products with MS Office, Google Docs and other all-purpose documentation tools, according to research in Gartner’s “Market Guide for Software Requirements Definition and Management Solutions.”

Many other companies muddle through the best they can with clunky, kludgey, user-unfriendly legacy systems such as IBM DOORS.

Either way, when multiple teams are stuck with archaic tools that are a pain to use, Product Managers have a heck of a time keeping the people, the processes and the methodologies everyone must follow together.

Folks end up retreating to their silos of expertise, and that creates a bigger problem: When important product data is lost in emails or locked up in static documents, your teams fall out of sync, progress slows, important steps get overlooked and the product you’re responsible for becomes much more likely to fail.

As a Product Manager, you can’t afford to waste time on tools that bog down critical processes, because you’ve already got more than enough on your plate and on your mind:

Tall tasks:

  • Translating high-level strategic objectives into tactical implementation and making sure that everyone involved stays aligned.

Pressure points:

  • Connecting customer needs to product features.
  • Providing road map visibility and updates when things change.
  • Reconciling the opinions of stakeholders with concrete data and communicating critical details  to the appropriate audiences.

Burning desires:

  • To be able to easily communicate strategy, vision, project status, blocks and needs in all directions.

With Jama, Product Managers can turn “Mission:Impossible” episodes into “MacGyver” epics.

How so? You’re able to…

  • Capture customer feedback, prioritize new features and plan releases faster.
  • Gain greater visibility into what is being built to ensure the product delivers what your customers, and the business plan, expect.
  • Communicate easily with the every individual on the project and program to get clarification and decisions made, regardless of location.

Read The Product Delivery Problem (hint: it’s not you) to learn more about the ways Jama can bring your team into alignment and up to speed.

Check out other ways Jama helps business and engineering teams get and stay aligned:

How Jama Helps VPs of Sales

How Jama Helps VPs of Product

How Jama Helps Systems Engineers

How Jama Helps QA Leads

How Jama Helps Business Analysts

How Jama Helps Project Managers

When you hear the word “workflow” do you get excited, like you can’t wait to spend a day in front of a white board with a cross-departmental team and map out how you will all work together happily ever after?

Or, are you like most people and dread the thought of going through the process of designing and implementing a new workflow, no matter how badly you know your organization needs to change the way it works?

Anyone who’s been through an organizational change in how teams are to work together already knows this process is never easy. Just thinking about this may trigger thoughts of:

  • Heavy, unmaintainable process that doesn’t scale
  • Wasted time going around in circles trying to get buy-in from everyone involved
  • Rigid rules that lead to impersonal interactions
  • And maybe some overwhelming diagrams or documentation just to add salt to the wound

When the Product and Engineering teams here at Jama set out to establish a workflow between our two groups we had some of the same concerns. We were already productive, but we were growing quickly (and still are!) and we knew we needed to establish a formal way of communicating, one that would scale over time.

What makes a good workflow?

So the first question we had to answer for ourselves was, “What makes a good workflow?”

Simply put, the intent of any workflow is to help people better work together.

But people aren’t simple. And moreover, the products they produce aren’t simple, either. As a society we now rely on critical software and technology to run our economy, our military and to save lives. These products are, by definition, complex.

So as we developed our workflow at Jama we focused on the aspects that we knew would make us not only work faster, but better. Our Engineering and Product teams were already committed to Agile practices for its focus on people first, and even have an in-house coach. What we needed to improve was our communication to the Business, and also aligning all three groups around common goals—the “why” of what we’re building. So we decided to document and formalize our commitment to Agile by designing a workflow around these tenets:

  • Facilitate fluid communications without a heavy-handed process
  • Enable quick and confident decision-making

Getting Down to the Science (Behavioral Science, that is)

But we didn’t stop there. With my educational background in neuroscience and human behavior, I knew that groups can agree to a new workflow on paper and still fail to maintain it, especially in growth periods, which we were (and are!) definitely in.

We’d need something more than a beautiful flow chart. We needed to know what makes teams adopt new ways of working and stick with them.

I started investigating some of the latest research in how people work in teams and how they adapt to change. I found some gems that applied to workflows, as well as other struggles in my life, because really, what part of life isn’t about dealing with people and adapting to change?

There were two theories that I found particularly applicable to our team:

  • Status Quo Bias
  • Choice Overload

According to The Behavioral Economics Guide 2014, Status Quo Bias refers to the fact that “…people feel greater regret for bad outcomes that result from new actions taken than for bad consequences that are the consequence of inaction.”

People don’t like change. Not surprising. But what this research also says is that people are especially averse to change in work processes, even if what they’re currently doing isn’t working, because they’re worried that if the change leads to failure they’ll be liable and life will be worse than it is today.

Also, people will say that they like choices, but if they’re presented with too many options they become confused and overwhelmed and get choice overload.  They need to have the right amount of information, at the right time, so they can evaluate and make a decision on a purposefully limited amount of criteria with just the right amount of, and right type, of data.

The Agile Workflow Design

Like I said above, a good workflow supports the people within it and improves their working relationships. So the first thing we did was get clear on who are the people who make up product development teams, what are they each responsible for in the process, and how can we support their communication with each other.

click to enlarge

click to enlarge

This chart illustrates an example team, across departments, and the people who need to weigh in on strategy, plans and key decisions, and at what point in the product development cycle. This is a good, if simplified, representation of what our customers tell us about their teams’ compositions and dynamics, and also how we work at Jama.

click to enlarge

click to enlarge

And this–finally!–is the Agile Workflow Design. If you’re familiar with Agile, you’ll recognize many of the steps. This chart also shows which tool holds which types of data, in our case, Jama and JIRA, indicated in the lower left corner.

Next, I’ll zoom in on the key steps in the Agile Workflow Design. The diagrams below don’t look exactly like the one above, and are designed to illustrate key points in the Workflow.

click to enlarge

click to enlarge

Here the Product Manager or Product Owner documents the business need, or why we’re building this feature and who will use it and the value they’ll get out of it. This information is documented in Jama, indicated by the orange text.

click to enlarge

click to enlarge

The Product Manager or Owner collaborates with Engineering—in this case, the Lead Developer—to understand the business need and develop Epics. You’ll notice two new things in this diagram. The first is the progress bar above the “Business Need” box, which indicates progress to completion. Right now we haven’t started development so it’s at “0%.” The second thing is the blue “Connected Users” icon. Right now there are 3 people involved in this project. Both of these indicators are taken directly from the Jama interface, where you can see current progress and the individual team members involved in a project, which is really useful especially if you have a global, distributed team, or, in our case, a growing company where you may not yet know everyone’s name!

click to enlarge

click to enlarge

Now development work has begun. Epics have been broken down into stories in Jama, and that data has been synced, in this case, to JIRA (indicated in the blue text). Progress is tracked in JIRA and that data is synced with Jama. As indicated by the progress bar, we are now 15% complete in this work, and with the introduction of the developers, we now have 5 Connected Users.

click to enlarge

click to enlarge

The QA team has been testing all along the way, but as we get closer to complete it’s a great time to confirm we’re still on track.  We’re logging defects in Jama and syncing the status back to JIRA. We now have 15 Connected Users and we’re 65% complete in this work.

click to enlarge

click to enlarge

Testing is complete and we’ve confirmed that this feature meets the business need. We’re now at 100% and ready for release!

And that’s the Agile Workflow Design, explained. Of course, for our team at Jama coming to this design was a gradual process, which included many conversations and agreements made. We’re always improving it and it’s been worth the effort. Now our teams are more connected to the business need behind our development plans, and other departments, such as Operations and Marketing have more insight into what we’re building, making it easier for those teams to do their jobs well.

Take This To Your Team

I want to leave you with a few useful things to guide you the next time you find yourself in a process meeting, or designing a workflow:

  • Workflows should connect people first, and data second. After all, it’s people who actually get the work done. It doesn’t mean that codifying a series of steps and procedures is a bad idea, as many people are building very complex things and they may just need to account for twenty well-defined steps in order to get a quality product out the door. What I’m highlighting is the fact that at every touch point where people need to exchange information there’s an opportunity to make that interaction as smooth and productive as possible. When you focus on this you’ll have an easier time getting the group working together in a “flow” as much as possible.
  • Remember the “why” of what you’re building. Stay connected to your original business goals, and build in opportunities to adapt to change as it inevitably arises. Don’t wait for people to protest since Status Quo bias inhibits that.
  • Avoid Choice Overload by limiting the number of available options when a decision must be made.

Hear more about team collaboration in the recently recorded version of our Agile Workflow Design WebinarWe cover these concepts and more, in-depth, and answer questions from the webinar audience.

About the author: 

Robin Calhoun is a product manager for Jama Software, as well as a certified ScrumMaster. Calhoun users her education in human behavior and economics to direct product decisions and team management, combing this expertise with the ever-evolving body of knowledge in Agile development practices. Before joining the Jama team Calhoun was a product manager at Tendril, defining data-driven Energy Service Management products. She holds a degree from Columbia University in Neuroscience and Behavior.

The following guest post is the third in a series of four articles by innovation agitator Alberto Savoia (find the first here). Throughout his career as a serial entrepreneur and Google employee, Alberto has experienced great market successes–along with a few inevitable failures. In this series he’ll share his knowledge about why products fail and provide recommendations for beating the odds. 


In my previous two articles (found here and here) I introduced The Law of Market Failure which states: “Most new products will fail in the market, even if they are competently executed,” and identified failure in premise (i.e. building the wrong product to start with) as the most common, and hardest to recover from, reason for failure. In this article, we begin to look at how we can test a new product’s premise before we invest too much in it.

All new products begin with an idea. If all you have is the idea, however, the most you can do with it is to solicit opinions based on it; and if you do that, you are likely to run into a couple of problems that may seriously derail your decision-making process:

The Lost in Translation Problem: An idea is an abstraction–and a subjective one at that; it’s something that you imagine or picture in your head. The moment you try to communicate what you see in your mind’s eye to someone else you run into a challenging translation problem–especially if your idea is new and different from anything else they’ve seen. The way you imagine the new product and its uses may be completely different from the way they imagine it.

The Prediction Problem: Even if your audience’s abstract understanding of your idea is a close match to your original intention, people are notoriously bad at predicting whether they would actually want or like something they have not yet experienced, or if and how they would actually use it.

In my book, Pretotype It, I introduced the concept of Thoughtland, a fictional place where unrealized and untested new product ideas live. In Thoughtland, every idea can be a winner or a loser–depending on whom you ask … and how you ask it. This can lead to two dangerous outcomes:

False Positive: People like your idea, they think they understand it and can see themselves using it. They give you thumbs-up and tell you to go ahead: “Go for it! If you build it, we’ll definitely buy it and use it.” Fueled by such positive feedback you proceed to implement the idea. But after you launch it, all that enthusiasm and all those plans to buy and use your product are nowhere to be seen.

False Negative: People just don’t get your idea, or it makes no sense to them. They don’t see what you see. When you talk about your vision, they think you are hallucinating: “Have random people follow you as you write 140 character blurbs? You’ve got to be kidding!” As a result, you drop any plans of implementing your idea and move on. And a few months later another company launches a very similar product to great success.

False positives can lead you to believe that your idea is immune to The Law of Market Failure, so you invest too much too soon in a new product that will eventually flop. False negatives, on the other hand, can scare you away from giving your idea a chance, and you end up prematurely scrapping the next Twitter, or Google, or Tesla.

To minimize your chances of getting false positives or negatives you need to collect something more substantial and objective than opinions–especially when the people who give you those opinions have no skin in the game. And the only way to do that is to transport your idea from Thoughtland to a more concrete environment–let’s call it Actionland.

In Thoughtland you use abstract ideas to ask hypothetical questions and collect opinions.

Thoughtland: Ideas -> Questions -> Opinions 

In Actionland you use artifacts to prompt actions and collect data.

Actionland: Artifacts -> Actions -> Data 

Let’s say, for example, that you have an idea for a computer monitor stand with sensors and motors that automatically moves and adjusts for optimum ergonomics. Let’s call it The Last Stand–as in: “You can now last longer working at your computer.”

If all you have is the idea and, perhaps, a drawing, you are stuck in Thoughtland. You can go around your office, explain the idea to your colleagues and ask them questions such as: “What do you think of this?”, “How much would you pay for it?” You can reach out to other companies and talk to HR departments: “Would you consider buying this for your staff?” “How many would you order?” That’s a lot of hypothetical questions and subjective answers (with no skin in the game)–not a lot to go on.

Of course, you might learn a few useful things in the process. For example, that most people would not use their own money on The Last Stand, but would be happy to try it–if the company pays for it. Before you make an expensive new product decision based on a flimsy combination of ideas, questions and opinions, however, remember The Law of Market Failure.

As I’ve mentioned in my first article: “In criminal law, a person is presumed innocent until proven guilty. When it comes to market law, we should presume a potential new product to be a failure–at least until we’ve collected enough objective evidence to make us believe otherwise.”

And to collect that objective evidence, you need to move from Thoughtland to Actionland.

You can do that by building a proper prototype of The Last Stand (i.e., an actual stand with sensors and motors–and all the software to run it.) But such a prototype will be costly and will take weeks/months to create.

On top of that, working prototypes are great for determining the feasibility of a new product (Can we build it? Will it work?) but are not sufficient for determining if there is a viable market for it.

Wouldn’t it be wise to objectively test and gauge the potential market for The Last Stand–at least a bit–before making a major investment in prototyping it? Are there other artifacts we use can to collect market data that are simpler, cheaper and quicker to build than a prototype? Yes, between abstract ideas and proper prototypes there are pretotypes:

Pretotype, noun: An artifact used to test hypotheses and collect data about the market appeal and actual usage of a potential new product objectively and with a minimal investment of time and money.

Pretotypes help you to “make sure that you are building The Right It before you build It right.”

In the next and final article in this series, Pretotype It, I continue my discussion of pretotypes and show you how simple pretotypes can quickly take you from Thoughtland to Actionland and be used to collect valuable market data. Please share your thoughts about decision-making in building products in the comments below.

Read the fourth and final article in the series: Pretotype It.

About Alberto Savoia

As a serial entrepreneur and an early Google employee (where he led the development and launch of Google’s AdWords), Alberto Savoia has experienced great market successes–along with a few inevitable failures. Most entrepreneurs and innovators respond to failure by licking their wounds and moving on to their next idea. But Alberto decided to first deal with the sting of failure by stinging back. Between 2008 and 2011, while still at Google, Alberto became a serious student of failure in new and innovative products. After reading dozens of studies and analyzing hundreds of new products, he was able to identify the main cause for why most new products fail in the market, and developed a set of techniques, which he called Pretotyping, to minimize such failures.

The concept, techniques, tools and metrics of pretotyping were an instant hit within Google; and soon Alberto found himself teaching pretotyping at Stanford University and at many companies, from startups to Fortune 500. His handbook “Pretotype It–Make sure you are building The Right It before you build It right” has been translated in many languages and has become an invaluable guide for thousands of innovators and entrepreneurs world-wide. Alberto’s work on innovation has been recognized with numerous awards, including The Wall Street Journal Innovator Award. Learn more about Alberto on his website and follow him on Twitter @Pretotyping.


Note: The following is an excerpt from our Forrester Consulting commissioned report, The State of Modern Product Delivery. Read the full report for key insights on the current trends and challenges in product delivery.

Diversity of opinion is good, except when it gets in the way. Differing priorities compound the difficulties of product development when they lead to conflicting signals. Product development teams often find themselves caught in the middle, negotiating uneasy compromises between parties that see the customer problem differently. As with most forms of counseling, getting the issues on the table and clearly communicating goals goes a long way toward resolving conflicts.


  • The customer often lacks a consistent voice. Different functional groups will see the customer problem in different ways. None is completely correct, yet often each group sees its issues as the most important. The reality is that no product is complete until all perspectives are fairly represented. Getting the issues on the table to make the choices clear helps defuse the conflict and create healthy discussion.
  • Executive leadership may need to arbitrate. One of the benefits of active executive participation in product development is that misalignments, once spotted, can be quickly resolved. Differing priorities are often the result of organizational misalignments that are beyond the scope of the typical product team. Engaging executives, on the right level and the right time, can resolve the conflict before it affects product delivery.
  • Confused priorities lead to confusing products. Customers become frustrated with inconsistent solutions. When services or support offerings don’t align with the product they have purchased, dissatisfaction sets in. Ensuring a consistent customer experience goes far beyond the product itself.

Read the full Forrester Consulting report on The State of Modern Product Delivery complete with key recommendations. 

Looking for Jama Contour? It’s still here as the solution for collaborative requirements management software, we just dropped the “Contour” and added a “Connect.” Meet Jama Connect! We’re excited to begin the next chapter of our story: redefining product delivery.

Product delivery involves the entire company. It doesn’t start with Product Managers defining requirements and end with Engineering and QA teams delivering a finished product. Successful product delivery requires connecting the right people in a company to take strategies and concepts all the way to market and ultimately translate them into business value.

Jama Connect builds on Contour’s proven requirements and test management success. It extends the current collaboration capabilities amongst the team, allowing them to capture ad-hoc conversations and decisions within the context of their projects and items. Most importantly, it provides product teams the ability to engage stakeholders outside the team into the right discussions to make timely decisions that will be part of the project’s system of record.