How a Bill Becomes a Law… or How an Idea Makes it Into NX
Every company has a process where ideas become reality. As a product manager for NX, it’s my responsibility to guide projects from concept to completion. Luckily for me, it’s the most fun and satisfying part of my job.
While small projects may be handled differently, generally executives and upper management set the direction and priorities of the project. Product Management aligns product strategy with corporate strategy and makes project plans to fulfill with detailed requirements. Product Design plans dialogs, user interface and specific workflows to support the project. Development determines the data model, methods, tools and effort required to implement the product design. And QA (quality assurance) creates a testing plan with use cases. You the users provide feedback through beta testing, user group meetings and face-to-face discussions, and of course through enhancement requests and problem reports.
Certainly this isn’t groundbreaking or surprising. The fun part of my job comes in the execution and collaboration stages. While each group has its dedicated role, each also has the opportunity—no, the responsibility—to participate in the actions of the others. Often a developer will bring up a customer use case that I missed. Or QA will determine a better workflow than that of Product Design. Or rarely, I’ll propose an actual valid software solution. While I’m ultimately responsible for the end result, no one takes my word as the final one, and it’ a good thing they don’t. Good ideas and objections come from everywhere, and often it’s the debate that produces the best outcome.
Let’s take a recent case. The executive direction was that NX Routing must support 4th Generation Design (4GD) fully. This is a large task, so there were many steps between that and a workable set of projects. It was so complex that we actually started a release early with proof of concept work. In the end, one of the final projects was for a new routing path creation tool that would work in 4GD. An easy choice would be to retrofit the three existing tools, but in the end, we decided on a single all-new tool. The decision was mostly made by Product Management and Development Management based on the balance of difference in work required (with somewhat higher initial cost); lower recurring cost with a single new, easier-to-maintain tool; and the benefit to the user of a single, more capable function.
Then the real work begins. There is a series of paperwork, processes and approvals one must go through, all to document and track progress. Siemens PLM Software is a distributed company with people involved in this project scattered across the U.S., Europe and India, so we work primarily via web meetings and emails. We did get together for a couple of workshops and beta testing, however. I’m overjoyed that no one takes mine or anyone else’s word as final. It would be easy to just take the requirements from early on and move them along through the process. Just doing your job… But by questioning each other’s plans, we eventually arrive at much better ones. True, at times it can be frustrating, sometimes even contentious, but ultimately, the work is fruitful.
One nice, simple example of this came long after the final approvals of the user and functional requirements during coding. During a demonstration of an early build of the new path function, we noticed that when the cursor snapped to one of the xyz vectors, the color of the line changed. A little later on, when an object was selected, grey dashed lines appeared showing the intersection path clearly. Neither of these was specified in the requirements! While writing the software, the developer needed to define a color and font for the snapped line. Noticing that the coordinate system in the corner shows the x-, y- and z-axis in red, green and blue respectively, the developer decided to be consistent. Later when testing the code for determining the intersection, the developer added the grey helper lines to make it easier to see if the solution was correct. The developer then asked if we thought that the users would find these helpful, too. Yeah, I think so!
While this example contains relatively small improvements, it is indicative of the kind of solid, positive contributions made by everyone throughout the process prior to the next NX release. Some contributions are tangible like this one; others are corrections and additions to use cases and workflows. There’s even preparation for future improvements like when QA staff submit enhancement requests on the new functionality.
You are encouraged to participate in the process and submit your own enhancement request to GTAC. Enhancement requests are routed to the responsible product manager for that particular area of NX. vThese requests can be considered at any time, but most frequently are addressed with other enhancements in the same area when larger projects are proposed.
When submitting a request, it’s most helpful if you include the workflow around the request. Give us the big picture view. A good guideline is to describe the problem, not the solution. Describe the end result, not the method to get there. That keeps options open and gives us as product managers leeway to find a solution that works within the current capability and future vision.
Quick case in point was an enhancement request (also called an ER) that was very specific and odd. From speaking with the user, we determined that the workflow was actually a workaround for a function that wasn’t working properly. The workaround required the requested enhancement in order to complete the task. Rather than attempt to fulfill the ER at some later date, we converted the ER to a Problem Report (PR) to fix original function. That cut to the root of the problem, allowing us to deliver a solution faster.
The enhancement request process is one way you have direct influence over the direction of the product. Participating in beta testing, attending users group meetings with us, or contacting us directly are other great ways to make your needs known.
I look forward to it.
Doug
About the Author:
Doug Peters is the NX Product Manager for electrical and mechanical routing applications. He first joined Unigraphics Solutions in 1999 as a Business Solution Consultant in the Global Sales and Service organization. Doug received his Bachelor of Science degree in Mechanical Engineering from Rensselaer Polytechnic Institute in upstate New York. In his free time, he enjoys spending time with his wife and two daughters, hiking, skiing, and recently took up running.
