Category: product management

How best to ask for resources?

Imagine that you have to make a business case to your upper management for a product/project you want to get funded. There are two ways a product manager can ask for this:

1) I need $$$$$ and XXXXX number of people to do this project?

2) I have this idea that I have vetted with customers and prospects, here is the total size of the market, this will help us move the business forward, this would establish us as a market/thought leader, here is potential revenues we could bring in, what do you think and do you agree we need to do it?

Which do you think is going to be received well? Of course answer 2 (provided you have done enough research). The obvious question that will be asked would be – what would it take? And the answer is 1). But going in there with guns loaded just with 1) is not going to get anywhere.

The other benefit with 2), is you are asking for input whether it is the right thing to do – you are engaging your management to help you make the decision. Once you have the buy in that the idea/product is worth doing, they will open up for your justification for resources. But the common mistake made by product managers is doing 1) with no luck.

State of You?

As a product manager, you are quite busy doing product roadmaps, gathering requirements, working with cross functional teams, getting the messaging right,writing positioning statements etc. You are busy trying to do all the work with less time and resources available at your disposal. In the midst of this chaotic professional life, have you taken the time to evaluate how well you are doing growing your career, building value for yourselves such that your market value is increasing? Yes, the first and foremost thing we should focus on is building value to our employers (that is what we get paid for), but it is also important that you spend time adding value to yourselves. After all, I doubt that most of us want to do the same thing and work for the same employer for the rest of our working lives .

One technique that is useful is creating an honest assessment of the one product you are in full control of – YOU!!. The way I did it the other day was to create a list of all the skills an ideal product manager should have (if you don’t know the full list, read a bunch of job descriptions for product managers in your industry and look at the requirements or skills being asked for and then create the list) and then made a honest assessment of where I currently stood on a scale of High, Medium and Low (High = strong, Low = weak). I also did an assessment of what my personal interest is for each of these skills. For example, as a product manager, one is required to help legal with contracts – I consider this as a necessary evil that I as a product manager has to live with, but not something I want to get very good at. On the other hand, product positioning or market sizing is something I have great interest in and should have a strong skill.

Once you do this exercise, your strengths (High skill set, high interest) and weaknesses (low skill set, high interest) is going to stare at you. Now you need to create a roadmap on how you are going to work on your weaknesses and figure out what projects you may want to take on (read “initiative”) at your current employer to add more value to your employer and yourselves.

I have done mine and found this very useful and I intend to use this once a year to evaluate my progress and analyze the State of “Me” going forward. The above technique can be used by anyone – engineers, scientists, doctors etc. and not just product managers.

3 types of words in positioning statements

Other day, I was talking to Jon Hirschtick (founder of SolidWorks and my previous employer) and we were talking about positioning statements. Jon had an interesting way to put it – he said words in any messaging consists of three types of words:

  1. Blather words: In other words, marketing buzzwords – integrated, extensible, scalable, value added, synergy, paradigm, next generation, flexible, configurable etc. – so commonly (mis-) used that it adds no differentiation to your message
  2. Glue words: Words that you are forced to use such as “and, or, the, with” etc. Does not add to your message but necessary to hold your message together
  3. Keywords: These are the real things. This is where you need to spend your most time carefully picking them. Choose simple words that communicate the essence. Use what will resonate with the audience, words they can associate with, words that will stick with them.

Jon has put this out in very simple terms that this will be my guideline in all messaging that I do from now – positioning statements, key messages in my presentations, marketing material etc.

It is not what you say but how you say it !!

Have you seen the latest HP’s TV ad that features Burton snowboards? In the ad, the narrator  says ” … it still did not catch on, people just did’nt get it. Maybe it was not what we were saying, but how we were saying”. This is true with many products. Positioning messages are key for successful products. You got to simplify it so that someone who does not know much about your product, gets it.

McKinsey recently published an article on  “Crafting a Message that Sticks: An interview with Chip Heath” that talks about how executives spend months developing a great idea, but then just hours as to how to communicate the idea to their employees, customers or partners. Chip says “It’s worth spending time making sure that the lightbulb that has gone on inside your head also goes on inside the heads of your employees or customers.” Simplifying a message does not mean dumbing down a message, but capturing/highlighting the core elements of what you have to offer in a simple message that will stick.

How simple is your message for your products? Will it stick?

Pain points vs. Requirements

I was involved in a conversation last week where we were trying to unearth customer pain points. One of the software product managers explained that main pain points were integration and scalability. This is what set me thinking about the difference between pain points and requirements. The  two are not interchangeable – in fact there is a parent child relationship here which if you ignore, you could end up building the wrong or a less preferred product.

Pain points are what customers are going through because they do not have a product that solves their problem. For example, before the advent of wireless devices, a customer pain point could have been that he cannot make a phone call while he was in the car – notice that nowhere in this pain point is wireless mentioned. Putting wireless into this sentence would be jumping to a solution as to how to solve the pain point. It is extremely important that product managers understand the real pain points. Here are some other examples – all cooked up for illustration.

1) I am in sales and I get a lot of customer queries via email. I need to respond to these quickly to close the deals. This is especially true towards the end of the quarter. But given that I am travelling and in meetings at customer sites, I am unable to do this because I cannot get to my email unless I am in the office and this costs me time and money. For example, in one instance last quarter I missed closing a deal worth $1M by one day. (I guess RIM probably heard this a whole lot and came up with the Blackberry – but do you see anything about a Blackberry or a mobile device in the customer’s description of his/her pain point? – does it say anything related to integration or scalability or ease of deployment in the description?)

2) I usually get out of the office after the banks have closed. Hence I am unable to get to the bank before they close to withdraw money from my account. Hence I have to remember to withdraw money on Saturday mornings, enough to last me one week. I feel uncomfortable carrying all that money around where ever I go.  BTW, this is still true in a lots of places in India (what do you think could solve this? I can think of two – ATMs, credit cards)

3) I end up paying a lot of late fees because I forget to mail my payments on time or because the postal service takes more time to delivery my check to the credit card company. For example, last month I ended up paying $58 in late fees. It is hard to predict when exactly to mail the payment. I cannot afford to send the money way ahead of time because I have to wait for paychecks to get deposited (Could very well have been one of the pain points that created online banking)

You get the idea. It is very easy to fall into the trap of starting to describe product requirements and not pain points. It is not easy to do tjos because the creative part of our brains loves to start thinking about how to solve the problem. But take control – make sure that you understand the pain points very clearly before you start listing requirements or evaluating product ideas.

Balancing Strategy vs. Execution

Product Managers are responsible for managing the business of their products. This requires one to have a product strategy to ensure that the product continues to remain relevant to the marketplace in midst of new market trends and changing customer needs and also continues to provide a good size market opportunity so that the business can remain profitable.

But once you have come up with a decent product strategy that is well grounded in reality, flawless execution of the strategy is even more important. Strategy does not win customers, the product executed based on the strategy does. It is like a football game. The coaches can devise the best strategy that accentuates the strength of the team and one that exploits the weakness of the opposition, but unless the players execute flawlessly on the strategy, strategy means nothing.

All of this may sound common sense, but who was it that said that common sense is not too common. I have been part of some long drawn discussions which have involved debates about perfecting the strategy and spending countless hours trying to hone on the right strategy. I would rather have flawless execution based on a good but less than perfect strategy than having less than perfect execution on a perfect strategy (because I do not think one exists). Flawless execution can many a times can cover up weaknesses in strategy, provided one learns to adapt as one goes along. It is important to start rowing along a rough direction that you think makes sense and then iteratively steering the boat in the right direction as one goes along. You will come out a lot ahead this way compared to staying on the shore and refusing to row until you figure out the absolutely perfect direction to row in. This is an easy trap to fall into, especially when you get involved in workgroups, strategic initiatives etc. By the time you get something accomplished via such initiatives (read “a long time”), the strategy could be outdated by the market changes that took place in the mean time.

Winning your first customers who will help you improvise is extremely important. When in doubt, lean towards execution than strategy because execution is progress, while purely devising strategy with no execution is nothing but stagnation. As a product manager, especially in the high tech market segment, stagnation is death !!

Now, do not mistake the above to be saying that it is OK not spending time setting a product strategy or to have an ever changing strategy – one that changes based on the latest fad or what you heard at the last customer visit. No that is not the point. Take time to devise a strategy, once it is good enough, stick to it and execute as hell. Once you have the product ready, sell it, get feedback from the customers and then figure out what you need to do next. Your strategy may still be sound or may need adjustments, but this is whole lot better than doing nothing and waiting to get your strategy right before you start executing.

Need more than a PRD? Functional specs to the rescue

Product Managers are all familiar with writing MRDs (Market Requirements documents) and PRDs (Product requirements documents). Are these enough to communicate to engineering all the customer requirements that would result in engineering building a product that is usable by customers to solve their problems? Unfortunately in my experience, a PRD is not enough.

PRDs are very good high level documents that communicates to all stakeholders what one needs to build – new products, key elements of a new product release etc. But when it comes down to detailed customer expectations of the individual features called out in the PRD, there is nothing in the PRD that helps out the engineering teams understand the customer requirements and expectations. This is not a fault of the PRD but calls out for the existence of a supporting document that builds upon what is stated in the PRD. Such a document is well known as the functional spec.

But after talking to my friends and acquaintances from different companies, I am surprised to find that many companies do not invest the time and energy in creating the functional specs upfront. The net result many times, is a product that does not meet the customer needs/expectations/requirements and one that sometimes is unusable and hence not sellable. Lack of a functional spec essentially makes a product manager hope and pray that engineering has exactly understood what needs to be build from one sentence/one paragraph describing the feature in the PRD. To have this happen, you either need very smart developers who can put themselves in the user’s shoes (and there are very few of these) or you have to get outright lucky (I think winning a lottery has better odds). This becomes even more important if you have globally distributed development teams who may not have the luxury to talk to your customers.

So what exactly is a functional spec and what does it need to contain. I was asked this the other day and I put the following FAQ together.

1) What is a functional spec?
Functional specification is a document that lists the requirements for a single item (project) listed in the PRD. It lists all the minimum requirements and the interaction requirements for any new feature including all graphical user interface elements being introduced by the new feature.

The functional spec is typically written by someone who intimately knows the user needs and user expectations. In many cases, this happens to be the Product Manager since he is expected to best know the user’s needs.

2) Why do need a functional spec when we already have a PRD and engineering design documents?
Functional spec is more detailed than a PRD. For example, a PRD may call out for a search utility or for a migration tool. There are multiple ways to solve this problem. A functional spec on the other hand would detail out all the solution requirements and also how the user interface should be presented to the user and how the user would interact with the UI.

Engineering design documents are documents written to design the internal architecture of the system such that the minimum requirements and the user interface called out in the functional spec can be implemented.

3) When is a functional spec written?
Functional spec is written before engineering embarks on the implementation of a new feature. The functional spec is reviewed, iterated and agreed upon before the start of implementation of the new feature.

4) Do all items in a PRD need a functional spec?
Not necessarily. This is something that has to be decided by the Product Manager and Engineering. For example, a project titled “Ensure that the new release supports backward compatibility – new client works with a old server” does not require a functional spec since this is a system requirement that does not have any new user functionality. But all projects that introduce new User Interface elements should have a functional spec.

It is also possible that in some cases, one item listed in a PRD may get broken into multiple projects by engineering. In these cases, one item in a PRD may end up having multiple functional specs associated with it. This is something that needs to be worked out between the engineering and the person writing the functional spec.

5) Who needs to review a functional spec?
The functional spec needs to be reviewed by the Product Manager, Engineering Managers, developer who will code the new feature and the QA engineer who will test the project.

6) What can a functional spec be used for?
Once agreed upon, the functional spec becomes the driving document for all downstream tasks including:

· Generation of any internal design documents

· Creation of test plans by QA

· Reference document for Tech Pubs to create product documentation

· Reference document for the field (system engineers, support staff, professional services) to get more details on any new feature

Having been a product manager for the last 12 years and having written functional specifications for products used by hundreds of thousands of users, a functional spec is one that I think is an absolute must. Just like how a business plan would have detailed financial projections and assumptions, items in a PRD should be supported by a functional spec. It is the document that explains to engineering the “devil in the details”. It is one thing I cannot comprehend product managers not writing early in the development cycle. Not writing it is leaving too much to chance !!

How useful are the error messages?

Have you got error messages when using applications that have made you wonder whether a real person wrote these messages? It has happened to me numerous times. The best error message I have ever seen is when Pro/PDM, a CAD data management product from PTC once crashed with the error message – “Gastronomic error occurred, exiting” – I am not making this up – this was in 1996.

Though software development has made great strides since then, the usefulness of error messages have not changed that much. I was visiting one of the websites today (I cannot reveal the site name), when this information message caught my attention.

error-message.jpg

I was quite happy to notice that they wanted to improve my shopping experience, but look at the message. I am left to figure out when the site would be down. What would it have taken to say the exact date and time when the site would be down – nothing. But I speculate that some web developer discovered a cute little function that could update the number of hours and minutes to shutdown real time and he/she would have said”Wow, cool”. If the person who put this message together had stopped to think for one second whether the message provided the useful information he/she wanted to convey (the information that his/her customers could process), he/she very likely would have changed the message.

Think about all the information you put out there for your users and think about how much of it would make sense to them. Your users don’t have your product as the center of their universe, they are using it as a tool to get their real job done. Do all the messages that your product puts out help them get their job done? – that is the only benchmark that matters.

It is up to us as Product Managers to emphasize to our documentation/development teams that error/informational messages put out by the product has a significant enough influence on usability and user perception of your product that enough attention should be put in writing user friendly messages (and not one that makes great sense to developers alone).

Apple is all about sales – customer service sucks

Yesterday, my Mighty Mouse, only 10 months old and the one I purchased with my iMac, stopped working – all I could do was scroll down and not scroll up. I decided to take it to the nearest Apple store in Natick – about 25 miles away. I also had a $600+ gift card from Apple and I intended to spend it. I am a great fan of Apple products (see my previous post where I have raved about Apple products). I walked in like a kid in a candy store confident that I will get a new mouse and then get some more of new toys with my gift card.

I talk to one of the reps at the store only to be asked if I have an appointment to replace my mouse. Excuse me, now I wondered if I have hearing problems. Yes, he was serious – he said I needed an appointment to talk to someone about getting a new mouse. He refers me to the manager who says the same thing – I needed an appointment with the Genius Bar and if I want, I could wait around 2 hours to see if they could squeeze me in – hallo, first of all, I don’t need a Genius to replace my mouse and two, I was not looking for a doctor’s appointment. I could see that there were at least 10 sales reps in the store, some selling new stuff, others just standing around waiting for customers to whom they could sell stuff. Now here I am, a very loyal customer being told to leave, drive back 50 miles, set up an appointment and then drive back another 50 miles the next day all for replacing a mouse.

None of this reasoning would go anywhere with the store Manager. He told me that they had a system in place and we had to follow the system (hallo, I am the customer) and it was put in place to be respectful of other customers – never mind, this customer being insulted. Only when I told him that I was intending to spend $700 in the store did something dawn on the manager. Not immediately, but after about 10 minutes when he saw me looking at the new iPod. He knew that I was serious about spending the money. He came by after 10 minutes and he said he will do me a favor (sure I am the customer and you are doing me a favor) and exchange the mouse. So why all the hoopla, if you could do this – it took him a mere 5 minutes. Amazing !!

Apple got away lucky – I had an Apple gift card and hence I was a captive customer. I could not exchange the card for money to spend it elsewhere – who knows even if I could do, I am sure that would need another Genius Bar appointment. I ended up spending all the money getting my new iPod, iPod shuffle and the Bose sound dock.

While I am happy with my new toys, I can tell you that I am still shocked at the horrible experience. Does this mean that as long as you churn out great products and the world is beating a path to your door, you can get away with horrible customer service? Maybe Apple will – but I don’t think this is a model anyone else would want to follow. After all, history is loaded with examples where companies once market darlings found themselves out of reckoning (Just ask Dell), when they forgot what got them there – the customer !! If my experience is what loyal customers get from Apple, maybe Apple deserves no better. Apple, you have got arrogant.

Consumer in charge? – Great Video

Here is a great video that I came across produced by Geert Desager of Microsoft – watch for yourself, it is fun !!

Customer experience – how often do you think about it?

Not often !! Think back to all the products that you have bought in your life – for how many of them has the buying/first usage experience been so good that you have remembered it. In my case – exactly two – iPod and iMac. In fact, I was so impressed with my iMac packaging, I took pictures while I was opening the package (see below). Setting up the machine was so much fun that I did not want it to end.

img_5973.JPGimg_5975.JPGimg_5977.JPGimg_5981.JPGimg_5982.JPG

Horrible first use experience permeates both hardware products and also computer software. I think before any new products are released to the market, the executive management and product managers should watch some real people (not designers, not developers) try to use their product the first time. That should stop claims every marketing department loves to make – easy to use, easy to deploy (my foot !!).

Steve Johnson of Pragmatic Marketing in his blog post On buying and using describes his horrendous first user experience with a JBL portable player for his iPod. Such examples are everywhere – so why do great companies like Apple get it right – they take the time and give it the right amount of priority during design. They are not necessarily smarter than the rest of us, they just know that their products are going to be used by people who are very different from them and hence take the time to think how best to design the product to make it easy.

Steve points out how product packaging gets shoe horned into a one size fits all approach for all sales channels because one of the channels exhibits high incidence of product theft. Companies should start paying more attention to how customers buy if they want to make differentiation especially in product areas where all products are starting to look like. After all, good looks sell. Otherwise, you will have people like Steve and me openly writing about our horrendous experiences with products on our blogs for the rest of the world to read. Welcome to the new world of bad PR !!

What can we learn from the New England Patriots?

Over the last week, I cannot tell you how embarassed I have been to say that I am a New England Patriots fan? I have loved the Patriots since I moved to Boston in 1996. Them going to the Super Bowl my very first year here in Boston helped of course (though they did not win it all that year). Then came the 2001, 2003 and 2005 seasons where they won it all. The last couple of years were heart breaking, but there was something about this team that made it everyone’s envy. The attention to every detail, the team camaraderie and the strong work ethic of  coach Bill Belichick who was called a genius by everyone. Then all of this fell right apart this last week with what has now become famous “videogate”, “spygate”, “cameragate” ….

All the respect I had for coach Belichick went right out of the window when I first heard about the spying episode. I was mad not just because he cheated but because I never understood why he had to do it. Here was a team that was retooled with some of the best offensive weapons and favored heavily to win it all again this year. Why would the so called genius, such a great leader who could bring out the best out of his players, falter by making such a stupid decision to stoop so low. I even thought of not watching last night’s game against the Chargers, but then it is difficult to keep me away from a football game.

What transpired last night completely surprised me . The team rallied around their coach in what I consider to be one of the best Patriots game I have watched in the last 11 years. Both the offense and defense had an air around them that they had something to prove. They brought their best game all for their wounded coach and leader. The San Diego Chargers unfortunately did not stand a chance right from the word go. At the end of the game, they even gave Belichick the game ball to express their support.

This is to me is what great teams are made of. I still do not approve of Belichick’s unethical ways and I don’t think I ever will. But as a product manager, I am very impressed how the team rallied around their wounded leader to pick him up when he was down. Maybe that is what true teams are made of. It would have been very easy for the team to throw stones at their own glasshouse, but no – what they did last night is probably what sets the Patriots apart from the rest of the league.

After all, it is what it is. They moved on and continued doing what they do best – winning football games.

Remove the unnecessary so that necessary can speak !!

This morning, while walking through Terminal 3 of the San Francisco airport to get to my gate, I happened to notice the design museum display near the moving walkways. The museum is titled “From Prototype to Product: Thirty-three Projects from the Bay Area Design Community“.Behind each display, were quotes of some famous people.

One of them caught my eye – it said ““The ability to simplify means to eliminate the unnecessary so that the necessary may speak”. After getting home, I googled it to find that it is a quote by Hans Hofmann. The reason I find this quote very interesting is because it captures what good product design is all about. Designing a good product involves spending more time deciding what features NOT to include than deciding what features to include. I would bet that designers of iPod had all the pressures to add a zillion features to it – an AM/FM radio station, ability to add/edit/delete songs etc. But they did not – because adding all of these features would have destroyed the elegant design. The end product does not do everything, but what it does it does very elegantly. To this day, I would be willing to pay more for a remote control that would do the five things I want to do – play, stop, forward, rewind, power on/off, instead of the other 500 features it has making it impossible to find these features. The office phone is another example. Try doing a conference call.

To do this right, you need to understand who your target user is and then saying no to features that are not needed by target users. You cannot listen to sales, they will tell you that you need everything under the sun. You cannot listen to just your existing customers, they will ask you for more and more features. What you need to do is get out and talk to real people who want to use your product – especially people who have not yet bought your product. Observe them struggle using the current products (your products or competitors) and then figure out what you can do to simplify their lives. It is not easy, but good things never come easy.

Voice of the customer – Tip#7 – Tackling the language barrier

Language BarrierUnless your product is used only in the US, you as a product manager should make sure that you are listening to the “global” voice of the customer. Customers in other countries typically have vastly different needs than customers in the US. Localization of your product is something you should account for in the very first release if you know that your product will be sold in non-English speaking countries. Even if your first release product launch plan is limited to the US market, you should make sure that R&D accounts for localization such that when you do decide to sell in the non- English speaking world, you will not have to rearchitect your product. Localization is not cheap, nor is it easy to implement as an afterthought.

You as a product manager should also plan on visiting these customers to understand their requirements before you build the product. Even users in the English speaking world have different needs – assuming that customers in the UK have the same needs as those in the US would be making an assumption to your own detriment. One way to figure out who or how often to visit non-US customers is to look at the percentage of established customer base (or potential market for new products) in the major geographic market segments. Thus, if 45% of your revenue comes from the North American market, 30% from Europe, 10% from South America, 10% from Japan then you should plan on visiting customers (prospects) in these countries using the same ratio. You should then use market segmentation based on verticals to figure out which specific customers to visit.

In my experience, on-site customer visits in countries outside of US/Canada are best arranged through your local rep. This will help you overcome the language barrier and also driving in these countries. This will also help you establish a better rapport and expectations with the aid of the local rep who is more in tune with the local culture.

In certain countries like Japan, it is difficult (if not impossible) to have high level discussions on the customer’s goals and tasks. Often, you meet with folks in the trenches who use your product everyday as opposed to management folks and hence your discussions usually revolve around a laundry list of specific enhancement requests. You should try nevertheless to set expectations and send them a discussion guide long before the meeting so that they know how you would like to structure the meeting. Here is where the local reps can really help overcome the language barrier. After all, whatever you want to send to the customer will need to be translated before it can be send.

Listening to the “global” voice of the customer is not easy and not cheap. But it is something you cannot afford to neglect if your product is sold internationally. With some careful planning, it can be done. If you are going to do this for the first time, make sure you budget enough time, money and resources for couple of “learning trips” before you can fine tune to get the most out of these international visits.

Top 11 things I learnt at SolidWorks in the last 11 years !!

After 11 fun years at SolidWorks, I am leaving to pursue a new career opportunity. I consider myself lucky to have worked at such an awesome company during a time when it grew from a startup to a force in the CAD industry. In 1996, it was the second job of my fledgling career and I don’t think I could have done it any better. I learned so much during these 11 years, got to contribute to a product used by hundreds of thousands of product designers, worked with some of the smartest people I have met and made so many friends over the years amongst my colleagues and customers alike.

Now it is time to move on and do the next big thing in my career. It is hard to leave a place where I knew so many people who shared the good and bad times during the different business cycles. But I believe that I will never know what I will find next unless I try. It could be the next big success or failure, but the learning cannot continue unless I try. I wish all my colleagues the very best in personal and business success for years to come.

I thought this would be a great opportunity to list the top 11 things that I learned at SolidWorks (yes, there is a lot more than 11) in the last 11 years that will guide me for the rest of my working life.

1. Hiring is the most important thing you do at work and always hire people smarter than you: Team success is what will determine your business success, so why not have people smarter than you working for/with you? If you have to micromanage someone or babysit them to do the tasks, why hire them? Hire slowly and make sure you have done due diligence.

2. A manager’s success is all about making his/her reports successful in what they do: Once you are a manager, it is not about “you” anymore. It is all about your team. Your job is to ensure that you are making your reports successful in their job. You have to ensure that their strengths are fully utilized. You will be judged by your team’s success.

3. You cannot move up in the company unless you train your replacement: You have to make sure that you are dispensable by training your replacement. Otherwise, you cannot move up and take up another position within the company. Pay attention when you are hiring – can your new hire replace you one day? Thanks to Aaron Kelly for teaching me this. I would not have made my move from Product Definition to Strategic Marketing without Bruce Holway.

4. It is all about “relationships” and not “products”: This is true whether it is with customers, colleagues, partners and resellers. When someone buys from you or when your colleagues work with you, you are winning their trust and they are making an investment in you. Trust once broken, cannot be repaired. Relationships you build will outlive any technology or product. In other words, it is all about “people” and not “products”.

5. Only viewpoint that matters is that of the customer: The answer is not in the building. You have to get out and talk to real customers and understand their “pain points”. In fact, none of the people in the building will buy your product, only your customers do. So take the time to figure out what your customers need and then solve their pain points with a kick ass solution. Worry about the competition, but worry more about what customers need. Respect the customer.

6. There is a big difference between products that customers will “buy” vs. products customers “like”: You should only be solving problems that customers are willing to pay money for (in some cases, you make money via the network effect that is generated by solving problems – eDrawings, 3D ContentCentral are prime examples). After all, business needs to make money to stay around (there are no two ways about it !). It does not make business sense to solve problems customers don’t care about. Never get enamored with technology and then start looking for problems that the technology can solve. Do it the other way. Find the real customer problems and then find the best technology to solve these problems and then make money out of it.

7. Be “market driven” and not be “marketing driven”. There is a big difference: Never thought how big a difference adding “ing” to a word could make.

8. Have technical and business arguments with colleagues as long as none of it turns personal: Make sure that all perspectives are considered when devising the best possible solution for a customer’s problem. Have heated technical/business debates if you want, but never ever make any of these arguments/disagreements personal. When you have these disagreements and then make a decision, you at least know that you have considered all possible solutions and picked the one that is the best. After all, the customer does not care whose idea it was, to them the idea came from SolidWorks. Either all of us are going to look like heroes or a bunch of idiots. Which would you rather be?

9. Have meetings before the meeting: If you are asked to present to a large group of people meet with the key stakeholders one on one before your big meeting. You do not want to get ambushed because you did not do due diligence on the material you are presenting. Meet with them one on one before hand and make sure to get their feedback on your thinking and ask specifically for any concerns they may have. You would then have time to do more research to address those concerns or list them as risks. If you do this right, the final meeting should be one of consensus and no “surprises”.

10. Trying and failing is a lot better than failing to try: All successful people have failed more than they have succeeded. No one writes about their failures. Failing to try is trying to fail. Never forget the lessons you learn from these failures. There is no better learning method than trying and failing, but never fail the same way twice. I have to thank SolidWorks for all the wonderful opportunities over the last 11 years to try new things and having the luxury to fail and learn from these failures.

11. Execution is the key to being successful: History is filled with people/companies who had great ideas and got nowhere because they did not execute. Devil is in the details. Many times, flawless execution can compensate for any flaws in the idea as long as you quickly iterate and continue to execute. Execution is the key.

%d bloggers like this: