Presenting another expert interview as part of our exciting expert interview series!
Paul Weismantel is an agile Product Management leader who specializes in a wide range of technologies which deliver innovation and a unique ability to link design directly to customer value and competitive advantage. Paul specializes in leading teams to success and financial and operational mastery of the day-to-day activities essential within the company. He has also acquired the skills to isolate and identify influencing action.
Tell us about yourself, your team, and your product development process.
Over the years I have lead cross-functional teams spanning all organizational functions in small, mid-sized, and large multi-national organizations. Core groups included engineering & development, marketing, sales, supply chain, finance, quality, and services.
In addition to holding sole contributor product management positions, I have led groups that managed various product lines and portfolios covering a variety of software, hardware, and SaaS offers in the B2B high tech space serving business as well as both civilian and military governments.
Over the years and to this day I have found in place and introduced or modified a wide variety of product processes, including various waterfall, agile, and ITIL derived approaches. The key to avoiding the process being a hindrance to reaching our goals was to mold the practice to the specific needs of the organization, technology, and market rather than having the process force unneeded changes.
Basically, take what works to improve our methods and discard the rest. Also, in each case these processes had to support a transparent gate process that communicated direction and allowed for input from across the value chain.
What advice would you share with new product managers/owners? What information do you wish someone had shared with you when you were first starting out?
The toughest and most critical challenge to product management is to “live” your job at the edge of the company. From early on I have urged product managers to “hate” their product and love their job. Admittedly, hate is an exaggeration, but from the time a new idea is born through the end of life it is the product manager that must constantly ask the question of WHY.
Why are we doing this instead of something else? Why did we develop this feature to work in a certain way if the customer is better served by another? When you continually ask why you avoid the inevitable trap of over complexity, and can uncover key areas of valuable added improvements your customers (and value chain) will take notice of.
This approach has its challenges given the desire and expectation that the product manager serve as the principle advocate for their product, both internally and in the marketplace. This requires developing a split personality sort of behavior that is built on pride of the work that has been done for the product at hand while always recognizing that the job is never done.
Finally, everything that is done for a product needs to be focused on removing pain from the daily job of all the people it touches. When considering anything being developed, the resulting delivery must be judged in this light.
What inspires you? Where do you look for new and revolutionary ideas?
Everything and everywhere. A bit vague, but this is critical to missing the next opportunity. Over the years I have found that one of the key traits needed for great product managers is an insatiable curiosity. This is a state of mind, not something you turn on when you walk into the office (or where ever you work).
It starts with constantly asking questions about what you see around you. Why is a competitor introducing this and not that? What is the worse part of a customer’s day’s work? Why is a sales channel in Asia asking for a certain pricing scheme?
I like to tell a story about a question I asked when eating at a restaurant many years ago. I noticed that the salt shaker had a thicker bottom then the pepper did, such that it held far less. Asking the manager what was going on he explained that this was a great feature for his business.
Being in the south, the humidity always resulted in the salt clumping, and he found that the diner trick of adding rice to absorb the vapor was unsightly to his higher end customers. He also noted that (in those days) there was a strong trend for less salt consumption. So this design meant he had less waste and a pleasant customer experience.
My takeaway forced me to take time to look at my products from a viewpoint of how we fit in our customer’s environment and how we are addressing trends rather than the tunnel vision inside the day to day grind. That product manager took the time to understand their customer’s changing needs, addressed them, and made this customer so pleased that he told his story with passion. That’s our job!
What tactics and objectives specifically go into a lean agile product strategy?
You have three separate things strung together here that have to be viewed separately:
First, I have found that adapting Simon Sinek’s Golden Circle to the product process, answering Why we do this, then How should it be done, and only then define What we should do, is key to staying on a course that tracks to Lean Principles, regardless of the development process used. Lean, or any of its preceding guiding principles are key to maintaining your path for continuous improvement in product, business model, and value.
Agile, or any part of the agile implemented in a group or firm must fit to the need. The biggest mistake I see is the trendy desire to use agile just because. These approaches require that the effort needed to develop the product can be “chunked” up into smaller pieces that can be completed and deliver user value without the “whole”. This is actually a rare situation. Thus the large number of efforts are just using a compartmentalized scrum process.
This is fine, but expectations have to be set accordingly. Many of the desired goals in invoking agile can be realized by simply opening up phased waterfall like prototyping cycles. In one case I implemented a modified Spiral model instead. This is just an organizing process, not the ingredients to the meal.
Product strategy is the overarching definition of what is needed to meet the company goals (content, timing, etc.). These are the ingredients and should be the result of applying the answers to Why, How, and What to initial ideas or incremental innovations. This must drive the prioritization and definition of what is needed from the development process (and the development resources, both internal and partners).
The product strategy, like the company strategy, must be constantly tested against the current and expected goals, and always done so within the context of its delivery to the market and the value (i.e., removing pain) it will deliver.
In your opinion, what are some of the most common mistakes made by product owners and their teams, and how can they be avoided?
The first issues I have seen grow in the last 10 years is the terrible concussion of what a product manager is and what a product owner is. If a firm is large enough to staff an “owner” embedded in the development team with the principle task of helping to manage the scrum (or whatever variant is used) process and backlog, then fine.
I see this role as a sort of enlightened project manager. But asking a product manager to serve in this role is asking for trouble. As I noted in (2) above, the PM must live on the edge, not locked for hours in a conference room with development teams.
Product Managers should not be micro-managing issues and small decisions that can and should be handled by development managers. Building a strong and trusting relationship between a PM and their partner technical managers (as well as other functional managers) is what “core-teams” are all about. These relationships are what powerful collaborations are built on, and create the leverage needed to scale capacity while also bringing everyone’s experience and ideas to focus.
How do you ensure a successful product launch? What are some personal touches you like to add?
Building great products and delivering them requires relentless levels of transparency, communication, and collaboration. Too many times products are dropped at the donor’s porch with an expectation that since the company made a decision to invest the dollars to build it, “they will come”. This is nonsense. Managing the launch of a new product, or a new version of an existing one, requires the support of every function in the company, its supply chain, sales channels, and most of all it must be tightly integrated with all of the other activities going on internally and in the market.
Even in the simple cases of a one product firm, timing with respect to customer activities, press attention, channel needs, and internal readiness can make or break even the best of offers. What I have learned over the years is that for everyone that the launch touches you need a message that specifically communicates why spending time on ramping up for this offer will make their lives better. The value from end to end is always about removing pain.
For more insights follow Paul on Twitter