I read two blog articles written by Mark Suster in his blog Both Sides of the Table – The Benefits Of Top Down Thinking and Doing the Right Things is More Important than Doing Things Right. Mark is entrepreneur, investor and general partner in GRP Partners. Mark is not writing about Product Lifecycle Management, of course. His name came on my radar after his company Koral was acquired by Salesforce.com.
There are two concepts that caught my attention. One is about top down vs. bottom up thinking. I found this association very interesting in the context of thinking about different engineering problems. I had a chance to participate in many discussions about various ways to implement PLM and ways engineers and designers are using our system. Lots of these discussions are comparisons of top-down vs. bottom-up approaches.
I specially liked the following fragment:
The wisest mentor I ever had was Ameet Shah, my partner on several projects. He taught me much that I know about critical thinking. He coached me that I had to start with the answers. WTF? How can I START with the answers? How can that be effective? ”Well, we know the basic structure of the problem we’re trying to solve and we have hypotheses about what some of the answers will be based on our experience. You need to put this all down into a structured diagram from the first week with the answers that tie to the logic of the problem we’re trying to solve.” — Heresy. — But he had more insight, “once we know the structure of the problem and our solution we can plan the data that proves or disproves our theories. The key is not to be wedded to our original answer. But by problem solving in a ‘top down’ manner we can be much more focused about what data we collect. We can also begin to socialize our answers with people in the company to get their reactions. That alone will help us solve the problems.”
It made me think about the following: how many of PLM projects started with the vague vision of results, such as “to organize documents” or “to decrease cost of product development” or “to streamline processes”. On the surface, they look like very valid goals. However, in most of the cases, PLM implementations are lack of definitions about how results will look like. So, starting from the “answers” seems to me a very appropriated approach in implementing PLM.
Now, let me move to the next topic. Do the right thing. It made me think how many things we are discussing how to implement PLM in the right way. How important is planning, project management, executive commitment, methodology, roadmap, resource planning? Don’t take me wrong, all these things are really key topics. However, many times, I hit myself thinking about products. This is what we are doing for the last 15 years. Maybe we need to think about it again and see if some fundamental shifts happened in the industry, technologies, product development.
My favorite quote from this post is about product features:
Similar with product features. One of the most important movements in software design in the past few years has been a return to simplicity – a move away from the Microsoft era of every release adding a new 150 unused features. One of my favorite sayings in this area comes from a portfolio company, RingRevenue, who like to say “ease of use = use and use = revenue.” I love that saying. If you don’t know WHY you’re adding features don’t do it just because you have a development team. Better that they work on new initiatives, performance improvements, operational features to help internal management or anything other than just cranking out features for the sake of it.
I found it very compelling to what I observe in software products for engineering and manufacturing. Bloody competition on features became a very typical norm. I can bring an endless list of the examples. If you will track product release announcements you can easy track and compare features, functions, marketing messages, etc. I had a chance to discuss the topic of complexity many times before. I think, we are going straight to the point when focusing on how to decrease the number of features and make things work simpler.
So, what is the conclusion? In my view, we are thinking about PLM in a bottom-up way. We are starting with terminology, lots of engineering details, opinions, thoughts, facts. If you have two engineers in the room, you may have three different opinions about how to make things happen. However, when it comes to PLM implementation, most of the vendors are making it in a very top-down way. PLM platforms, interoperability difficulties, long implementations, the absence of granularity. My feeling, this is a potential place for our problems. Maybe we need to start thinking top down and focus on what is important to achieve? However, when it comes to the implementation and products, let’s make it bottom up. It will allow us to have a solid foundation for everything we are doing. Just my thoughts…
Best, Oleg
