Monthly Archives: September 2015
This is the fourth in a series called “What does it takes to launch a Product?” and this entry focuses on the hard choices that need to be made between Product Management (Product Owner) and other stakeholders. There is never enough time, resources or money to deliver everything that is desired in a product. But in order to actually launch something – to get the product out the door – difficult choices need to be made. Here are three rules to help with the process:
Don’t build for the 1% (or 10% or maybe 20%)
This is one of the most difficult rules to adopt and live by because it is in our human nature to solve problems. But in order to get the product out of the design phase and into the marketplace, you have to be willing to say “yes, that might happen, but the odds are low so we will handle them manually or not at all.” Here is an example – what if a customer places an order for a product they already have. Will we issue an immediate refund? Will we notify them via e-mail? Will we convert them to another product? Before you build a complex, automated solution consider how often this will happen. If it is an ‘edge case’ or something that will not be a common occurrence, put a manual process in place and move on. Some in your company will probably fight you on this saying that it will be it harder for operations or customer service and that is true. The trade-off should be worth it because new products should equal new revenue and revenue solves most problems. Honestly, if a manual work-around really becomes cumbersome, it can always be automated post-launch. (Lean Product Development calls this the Minimum Viable Product or MVP.)
One of my favorite events every year is Sales Kick Off (SKO). SKO provides a great forum for sales enablement but it should be happening throughout the year and certainly with every product or significant feature launch. Let’s explore the key elements for successful sales enablement.
- Use cases– this cannot be overstated. Product Management needs to provide Sales with scenarios or use cases where the product will solve a real business problem. These use cases need to be simple to understand and easy to remember. The use cases used in Sales Enablement do NOT have to be exhaustive as that would be difficult and too much for sales to digest. They need to be simple and educational. With a proper grounding in ways the product could be used, the Sales force is armed to go out in the marketplace and find similar instances or even more complex scenarios. Product Management needs to provide Sales with simple examples so they stay engaged, pay attention and remember the products capabilities when they are in front of that sales opportunity.
This is the second in a series on “What does it take to launch a product?” This blog is about pricing which is a critical exercise in the process of launching a product. The observations shared here are focused solely on B-to-B sales (business to business, not business to consumer which has many different nuances.)
Golden Rule #1: Sales cannot set standard pricing
Every once in a while, I will hear from someone that their executive team wants sales to set the pricing because they are most aware of the marketplace and the competitive pressure. And while I agree that Sales should have a tremendous amount of input in the pricing process, they shouldn’t have the final say in setting *standard* pricing. It is a bit like having the fox watch the henhouse. Anyone with a quota has different incentives with regards to pricing than someone who is objectively trying to express the business value of a product. Once Standard pricing is set by Product Management (PM), then Sales will have an active role in deals-based pricing or ICB pricing. But Standard pricing must be owned by an organization without a quota.
Golden Rule #2: PM (or Finance) should define both Published Pricing and the floor
In the b-to-b world, like most other markets, pricing is negotiated. It is often the case that you want to publish your standard pricing which is the price that you would love to get, but you understand that there needs to be some wiggle room for the Sales force to negotiate. Our experience has been that when PM sets the standard and the floor, Sales has clear boundaries that they can move within. Some skeptics will say that Sales will always go straight to the floor and that may be true but it depends on a number of factors – namely their comp plan. If good salespeople will make more money by pricing closer to the standard/published pricing, then they will. Less experienced sales people or folks who are compensated on volume and not margin will likely go straight to floor pricing. But if PM defines it, the company should still be confident that adequate margins are maintained, even at floor pricing.
Today starts a series of blogs on launching a product. If you have heard me speak or been around me for 10 minutes, then you have heard me say that we recently launched 6 products in less than 3 years. I talk about it so much because I am so proud of this organization for accomplishing such an awesome feat. What does it take to launch a product? You have to define it. That sounds pretty basic, huh? Who would have a product that they couldn’t define? But the devil is in the details and there are several ways that products need to be defined. Let’s look at the nuances to better understand why this is harder than it looks.
Define for IT (Engineering)
You have to articulate each feature in detail so IT (Engineering) knows what to build. This could be a prioritized list of 10-15 things or perhaps 100 small features. The point is that Product and IT need to be on the same page as to the critical features, and what are the nice additions to be added, time and resources permitting. But for product management, the product definition doesn’t end there.
By most accounts, my first experience with an Agile roll-out (specifically Scrum) was quite successful. We went from 3 Scrum teams to 12, we increased employee job satisfaction measurably and we delivered faster and more accurately than ever before. We rolled out six products in less than 3 years and that is a remarkable feat. One that I am certain we could not have achieved without moving to – and embracing – Agile. So how did we do it? What made our efforts successful when many other companies have struggled or failed? Here are my perspectives on how we found success.
Agile is a movement that requires top-down leadership to say ‘this is going to happen, here is why it is good and we should all start rowing in that direction.’ Without that vision and dedication to making it happen, it would have been really hard to move out of Waterfall, which had been ingrained into the workflows, processes and the very culture of an organization. But top-down isn’t enough. You also have to have a group of developers that are eager to make the change. Like most things, you cannot force people to change their behaviors if they are completely unwilling participants. At our company, we were very lucky. We had incredibly talented developers across the organization who were anxious to try new ideas and see how we could innovate. That bottoms-up enthusiasm combined with the top-down dedication gave the movement to Agile a fighting chance.