In our quest for the best of breed productivity software tools for product managers, recently we interviewed Nils Davis, the Director of Product Management at Accept Software. He is a product manager for Accept360, a SaaS product for product managers working in enterprise environments- from idea management, portfolio planning, requirements gathering, through to execution stage.
Being a product manager himself, Nils has a deep understanding of his target market’s need. He and his team use their own product to manage the development, release, launch, and lifecycle of Accept’s portfolio management products, including developing and writing market requirements documents based on customer needs.
Here’s our interview with Nils.
Why did you become a Product Manager?
I started off in the high-tech industry as a technical writer. I could program & be highly technical, which was good for writing reference manuals for programming languages, but while at IntelliCorp in the mid-90’s, a rising star of the Artificial Intelligence world at the time, I thought I could use my communication skills better to help position and sell our products. So I switched to “Product Management” in its marketing organization.
Over the years since, in my role as a Product Manager, I have taken great advantage of my technical skills, which enable me to interpret technical capabilities to business people and help technical people to understand business and customer needs. I see a lot of my role as an “impedence matcher” to bridge this communication gap.
How did you end up at Accept?
In 2004, when I was a product manager for AppManager at NetIQ, I started looking at solutions that would help me manage my product requirements more effectively. Until I started using Accept360, I was using Word to manage my requirements, with all the attendant problems that most PMs experience – no single system of record, no analytics, no reporting. Accept came knocking on the door at that time and as I saw several demos I realized that Accept perfectly aligned with my goals for requirements management and product planning as well as with the needs of the rest of company. So I was a big fan of the company and the product even before I started to work here, and when I was ready to move on, I called up my contacts at Accept and told them I should manage the product!
What do you think Product Management delivers to an organisation?
As I mentioned earlier, Product Management is an impedence matching function. As product managers, we are holding conversations with regular people with particular problems. We also converse with the world of developers. We are the link between the world of regular customers & the world of developers. We help put developers in the shoes of the customer. We recast the technical solution for the customer so they understand how it solves their problems. So that’s one role of the PM.
Other aspects of the Product Management role is to be the Product Expert, the person for support people to go to, and be the one to talk to prospects & customers.
And, although I don’t totally agree that the ‘Product Manager is the CEO of the product’ (makes it sound like we don’t have bosses), I do think that like a CEO, the Product Manager needs to hold the view of every stakeholder – the customer, the business, Sales, Marketing, and Engineering, and understand how it all fits together.
From a tactical standpoint, requirements is one of the key ways that the Product Manager does all this communication with the organisation. Unless they have a solution like Accept360, Product Managers don’t have a good way to manage these requirements that focuses on supporting the entire business process of innovation. There’s a bunch of problems with using MS Word, Excel and Wikis for requirements gathering and bringing ideas in-house.
Why call it Innovation Software instead of Requirements Software or Product Management Software?
Looking at the business software market over the last 20 years, we realised that innovation – defining new products and getting them to market – is last major business process that hasn’t been automated. This is the process of capturing ideas, customer problems and refining them into specific new product concepts, or existing product enhancements, then driving those into portfolio and product planning, and eventually into product delivery. The backoffice, sales, accounting business processes have been automated for a long time through ERP, sales force automation and CRM systems. But Innovation – the core driver of value for companies here in the beginning of the 21st Century – is mostly done with Word and Excel and PowerPoint.
So our positioning as Innovation Software describes how our solutions help businesses figure out what new products and features should be driven into product delivery, based on the information we help them capture from the market, and aligned with corporate strategy via market-model-based analytics.
Organisations needed to take it into their own hands to manage their own innovation process.
I’m interested to understand how this product was created? What was the process utilised? Does Accept practice what they preach?
The product was initiated by a small team starting in 2004, well before I arrived. They did lots of research to determine features, especially in the area of figuring out how to automate the product planning process. We’ve always eaten our own dogfood, and the requirements – as well as the customers, the suggestions, and the rest of the market model – were captured in our own Accept360 instance (we call it Galileo). One technical decision that turned out to be very important was the use of the XUL UI framework, which also underlies the Firefox browser. XUL is kind of super-AJAX, from before AJAX even existed, and really accelerated our ability to get an extremely functional, 100% web-based enterprise app to market fast.
Over time, we have turned the product development process into an Agile process & we have also incorporated Agile capabilities into the product, to help deliver on our message of support for the full innovation process, from idea capture to product delivery.
One of our core differentiators is our strategic analysis capability, which is the reason I was so excited about this product when I discovered it. As product managers we know which customers want which of our new features, we understand how the new features deliver on various marketing and product themes, and how they will help or hurt us in various market segments of interest. With Accept360 we’re able to take all that market data – we call it a market model – and use it to do analytical prioritization of the universe of features that we could implement, to find the ones that we should implement to meet our corporate goals and objectives. For example, say I want to enter a new market segment, address the needs of six important customers, and support a new marketing push on enterprise support and security. Accept360 will help me find the requirements that best address that combination of needs, at the lowest cost.
Of course, as a Product Manager I may have a good sense of “the right thing” already, but Accept is not only giving me analytical justification for my gut feeling, but there are also sometimes surprises, which can make life very interesting!
And if you’re doing agile, as we are, these analytics address a key missing piece in most agile methodologies, which is how the product owner is supposed to prioritize the backlog. Usually that’s just a one liner – “the product owner will prioritize the backlog” – in the midst of an agile training. With Accept360 you have a concrete way to accomplish this, and it’s very empowering!
I use the system like this everyday. Our developers and program managers use the system to manage their requirements, task and defect lists, and to manage their agile sprints. And the great thing is that they can always go back to the analytics to understand why they’re doing something, which also empowers them to feel they are working on the most important stuff.
The system is also used by execs like our VP of Products, as well as the Sales and Marketing teams.
How is your product different from Feature Plan?
In 2004 when I was looking at lots of different solutions, I was not impressed with Feature Plan because I found it was too much like a spreadsheet. I previously used Word for writing requirements and I’m more inclined to a rich content-oriented system. Also, I was not impressed by the demo – it didn’t seem to solve my problem as a customer – and I didn’t relate to their marketing messages.
Over the years, Accept have competed against Feature Plan at times. Though both products are not inexpensive solutions, Feature Plan is less expensive than Accept. We usually win over Feature Plan, mostly because there’s a more complete story in the analytics capabilities, and we’re definitely more enterprise oriented. Our clients include high tech manufacturers, a lot of telecoms, and some large cell phone manufacturers, who are known for defining requirements extremely well – and who have hundreds of thousands of them.
The key differences between Accept360 and Feature Plan is that Accept360 manages the whole end-to end flow & integration process of product development, has better analytics and more of an enterprise focus.