Monthly Archives: August 2007

How to be a GREAT Product Manager (part 6)

Own the product from conception to completion and beyond

In my early product management jobs, I focused a lot on the process of product management. A CEO of a startup I worked for told me that my approach to product management was “very academic” in nature. He viewed himself as a “get it done by any means necessary” entrepreneur, while I viewed myself as a”get it done right” product manager.

The startup was a very sales/deal driven company, as many startups tend to be. Putting product management in place in such an organization is not easy. But having a process focus is very important for a product manager. Every other function, from sales to marketing to development to finance to HR implement processes.

But because product managers work across these functional units, people don’t realize or understand that even in small companies there must be a repeatable and scalable process to conceive, research, define, develop, test, launch, promote, sell, support and sustain winning products! :-)

And while product managers have a direct responsibility in some of these 10 areas and indirect responsibility in others, PMs absolutely have a core responsibility to oversee and align the activities of other teams across this entire process. I’m not talking about managing those people directly or telling them what they should do. I’m assuming people know how to do their respective jobs. What I am saying is that if you want to be a great Product Manager, take ownership (not necessarily full control) over the process and lead the teams in alignment through it.

Get alignment from the very beginning
From the start, as you (and/or your PM team) are doing your research, clearly define the context and vocabulary necessary to effectively convey the research results to the intended audiences. This vocabulary, whether related to personae/roles, business functions, consumer needs, product architecture or functionality or something else, will become key to bringing everyone into the same frame of reference. This is important because it helps to minimize misinterpretations and miscommunication during the product development and launch process. If people aren’t aligned early on in the process, you are likely to see confusion or conflict later on as requirements are implemented incorrectly or with unacceptable constraints.

As an example, before becoming a product manager, I worked at a company that was developing a fairly sophisticated reporting and visualization framework for business and financial data. One of the engineers was tasked with the requirement to create a flexible means to allow users to format and display numeric and character text (including time, date and multiple international currency values) dynamically for display in pop-up boxes when on-screen entities were moused-over. Are you with me?

He went off, did some research and without a lot of internal discussion, implemented functionality to address the requirement. I was responsible for documenting the functionality. When I saw what he had developed, I was stunned. He had created a flexible — but incredibly complicated — formatting subsystem. Yes, it could do everything and more relative to the requirement, but I’m certain only the engineer and a few other technical people could actually use it. The documentation for this functionality took 60 pages (out of a 600 page reference manual). When people in the company saw how complex it was, the functionality was removed from the product.

What went wrong? A number of things including lack of internal communication, lack of oversight, and lack of involvement from the product manager. Where was he during all this? I don’t recall exactly, but I think he was out, working with sales and trying to close some deals. Helping sales is good. Don’t get me wrong. But not when it comes at the expense of the product being built.

Get your hands good and dirty
During the development cycle, work to keep other teams such as marketing, product marketing, sales, sales consulting, support, channels, alliances and professional services informed and educated on the development status and product functionality. For smaller consumer products or websites, this may not be a difficult task, but for larger enterprise or data center software, this can be a daunting task.

For a major release of a large product, a development cycle will last 12 months or more. There are many decisions that are made during this cycle that need to be conveyed to downstream teams to ensure they can plan ahead for the impact of the new release.

Don’t stop until adoption is clear
Once the product is released, you need to stay focused on the product. You can’t let up and simply go start gathering requirements for the next release. Stay engaged with early customers, partners and the customer facing teams such as sales and professional services. If early customers are upgrading to the new release from a previous version, track those upgrades and follow up with the customers to see how the upgrade went and what comments they have about the new release.

Join members of the sales team on customer and prospect calls and listen to how they are describing and selling the new release, and what the reaction is from the audiences.

  • Are the salespeople on message?
  • Are the sales consultants adequately trained?
  • Do the demos hit on target?
  • Is the market need that you researched and identified oh so long ago, still as relevant and critical as it was back then?

These questions (as well as others) should be the focus of product managers (and product marketers) after product launch.

All too often, I’ve seen people work on a release, have it launch, and then essentially forget about it as they start focusing on the next release. Big mistake. If sales is struggling to sell the product, as the Product Manager, you need to take the challenge on and work to identify and remove the barriers.

Don’t look at it as someone else’s job because it isn’t. Would a CEO let a struggling VP of Sales flounder for a quarter or two? Absolutely not. As a PM, take your cues from the CEO and within reason, do what a CEO would do. Don’t wait for others to tell you what needs to be done. Take charge of your product, make sure it is built right and then ensure it trounces the competition.


Part 5 – Be an integrator, translator and communicator

Should I get me some of that?

Came across this special deal on an electronics retailer’s web site today. Until they explicitly pointed out the incredible savings I was getting if I purchased the CPU and motherboard together, I thought $79.97 was a pretty good price. With the exception of the green arrow (I put it there), this is an actual screen clip from the retailer’s web site. [click to enlarge]


Pointing out that I was saving only $.01 cost them the transaction. Given ecommerce is well over 10 years old, does it make sense that ecommerce sites are still this stupid? Wouldn’t someone managing the site create a requirement that says something like:

If the savings of our bundles are <5% of the combined price of the individual components, do not show actual component prices or the savings.

I like the retailer. They have a reasonably good website, but I’ll have to keep my eyes out for more of these “great deals”.


How does a PM gain insight?

thinker-small.jpgIn a comment on one of Alan’s posts, a reader, Michael, asks, how product managers can gain insight into market and customer needs.

He then lists a number of ways of doing this. I summarize them a bit for brevity.

  1. You could talk directly to customers.
  2. You could talk to a sample of customers (via focus groups or user group meetings or similar).
  3. You could rely on voluntary feedback (like those ghastly product registration cards so many things seem to come with).
  4. You could trawl the web looking for blog entries about your product.
  5. You could solicit feedback from your own sales team.
  6. You could ask your support staff what problems customers keep coming up against
  7. You could talk to industry pundits, who will guess what customers think of your product.
  8. You could ignore the customers and assume that they want what you want.

In another comment, Michael continues:

To pick an example, say you were involved with something like a consumer-grade digital camera (lots on units, lots of customers, scope for plenty of product differentiation). Given the volumes, you can’t talk to all the customers. Given the sales channel, you might not even know who most of the customers are. What can you do for something like this?

For the example above: a consumer-grade digital camera, let’s take a step back and talk about market segmentation. When the camera was being conceived there was an audience in mind for the camera. Today the digital camera market has matured enough that there are clear market segments at which cameras are aimed. For example, a simple segmentation could be:cameras

Now each of these segments defines different types of people, with different budgets, photography experience and photographic intent. When looking to design a camera, you would need to get a clear definition of the segment you’re aiming for, understand the dynamics of that segment (competitors, trends, subsegments etc.) and then start developing the product.

As for gaining insight, once you know the segment and the characteristics of that segment, you know the type of people to talk to: which end users, retailers, distributors etc. Those 8 questions listed earlier (OK, #8 — ignore the customers is probably not a good tactic) are all ways to gain insight, both before, during and after the product is released. Of course, there are many others.

Shifting to software, one of the most well known and oft-cited examples of gaining customer insight was Intuit’s “follow-me -home” program. This program had Intuit staff visit the homes of Quicken users and observe them using the product in their home settings. This program yielded valuable insights into what people did with the product in their home environment and led to several product enhancements such as an electronic paper tape feature in the Quicken calculator.

inside intuit BTW, if you want to read a great book on Intuit’s history and struggles, I recommend Inside Intuit. It covers, what we can now call, the early years, and if I recall [I read the book a long time ago] has a section covering the follow-me-home program.

The follow-me-home program was an example of ethnographic research. Essentially it is fieldwork; getting out into the real world and truly understanding the environment and frames of reference of those who will be using, recommending, selling or distributing your product.

One thing to keep in mind is that when doing fieldwork, it is best to include several people from your organization from teams other than product management. The reason? Because, regardless of how much primary research you do, you will always interpret what you observe and learn through your own personal frame of reference. The patterns you see when conducting the research will likely be somewhat different than the patterns others see. And the conclusions you draw may be different than the conclusions others draw.

Include members of engineering, market and even sales if possible and feasible in your research. Also take other product managers along. At minimum, you’ll have a control element in your sample of interpreters of the data you collect.

I honestly believe it takes a very skilled person to do ethnographic research well. You have to be able to put your personal biases and views aside, and not only listen to what others are saying and doing, but also ask the right questions (open ended, neutral questions) to solicit the input that is needed.

I’ll probably write about this more in future post, but one thing I see lacking in virtually all product management training is any coverage of the skills needed to do good field research. It is such a critical part of the product manager’s job, but I’ve yet to see that topic covered with any level of substance in any training courses aimed at product managers.

The question: “How does a PM gain insight?” is a good one. The answer, quite simply, is that there is no simple answer. Like most things, it takes ongoing effort, communication, thought and dedication.


Waiter: SE, Salesperson, or Product Manager?

Often when I am eating out, I ask the waiter for a recommendation. And so often the response is the same: the waiter responds by telling me what she prefers. Frankly, I don’t care what my waiter prefers! In fact, when I imagine my waiter eating, it reduces my own appetite.

I am really asking (i) what this restaurant specializes in, (ii) what is the most successful or interesting dish to most other customers, and (iii) what dish might fit best with my “goals” for this meal.

The waiter is in such a perfect position to help. She has contact with more eaters than anyone in the restaurant! If she is paying attention, she should have a good sense for what dishes are left unfinished and which ones receive rave reviews. She could respond with “what kind of meal are you in the mood for?”, or, “are you really hungry or looking for something rather light?” With that information in mind, she could recommend something that matches what I’m after and is most popular among her other customers.

Relevant to product management? I think it is:

  • are your sales people inquiring about customer goals before they send the quote or set up the demo?
  • do your sales people understand the typical goals of their prospects? Can they match prospect goals with individual capabilities of your product?
  • when you are talking with people from development, marketing, sales, operations, finance, etc., do they see you as the person who speaks for the customer, or just another person with an opinion?

As the product manager, you need to be the person who speaks to the most customers and prospects in open-ended conversations, and you should also have the broader data based on closed-ended questions.

Please don’t be like my waiter. Gather the data and share it with marketing, development, and sales. This is the best way to garner respect and cultivate your position as the true leader of your product line.

How to be a GREAT Product Manager (part 5)

Be an integrator, translator and communicator. Don’t be a terminator.

usa_network_traffic_map.jpgI’m sure you’ve heard the phrase that Product Managers are “the hub of the wheel”. I really don’t like that line. Who wants to be the hub of any wheel? That’s like saying someone is the hinge of the door or the latch of the hood. Boooring! And not true.

Product Managers are collectors, analyzers and dispensers of information. They are routers of information flow. And being a great product manager means understanding how to optimize the information flow so that other teams in your company who are directly or indirectly dependent on you for information get it in a timely manner and in a form they can understand and use.

The following image is a coarse example of the major communication paths that exists in a software company. The blue are internal teams and the red are external.


[click to enlarge]

I say a coarse example, because it really only represents a high-level view of how information flows. Not all links in the diagram contain the same amount of information flow; not all nodes contribute as much information as they receive; and to keep the diagram from becoming cluttered, a number of links that rightfully should be shown are not.

I call these communication pathways the Information Supply Chain. And as a Product Manager, you are directly or indirectly responsible for a lot of the product and technical information that flows throughout your organization. How many times have you been asked if certain functionality is in an upcoming release? Or when a particular release is coming out? Or the details of a beta program? Or whether any pricing or packaging changes are being made to address market needs?

People are asking these questions because they are making decisions and need information to decide wisely. You can have a significant positive impact on those teams if you understand what information people need, when they need it, and in what form they need it? If you can do that for them, they’ll be able to make educated decisions sooner, streamline their work and be more effective. Deliver meager, late or difficult to understand information, and the opposite occurs. There is a real top-line impact to poor information flow in a company.

If you really want be analytic about mapping out the flow, you can do that. You need to look at all the stages of the product development cycle, from conception to completion to launch and beyond, and map out what information different groups need and when they need it. One way to represent it is via a heatmap that may end up looking something like this.


[click to enlarge]

The coloured cells represent areas where communication happens during the development cycle. The deeper the colour, or higher the number (from 1-3 in this case), then the more activity and information flow that happens. As you can see, Product Management is deeply involved in the information flow through all phases of the development cycle, but most heavily early on and in the middle, whereas Marketing and Sales, for example, really start toward the middle and have heavy information flow from the launch stages onward.

By understanding this, you can determine what information you need to produce and deliver to those groups to optimize their activities and decisions. Keep in mind that this is not solely a task for Product Management. Ideally all groups in the company use this analysis to optimize their communications. But, if you want to apply an 80/20 rule (80% impact for 20% effort), then teams like Product Management and Product Marketing must be the first ones to optimize their information flow to other downstream groups.

As technology workers, we exist in an information economy. And just like the manufacturing world, where materials, parts and inventory requirements are optimized for efficiency and minimizing costs, information needs can be understood and delivery processes optimized for greater efficiencies. And because of our role in defining product direction and driving strategy, Product Managers can play a key role in optimizing the Information Supply Chain. The question is, are you up to the task?


Part 4 – The 4 Cs of Leadership

Part 6 – Own the product from conception to completion and beyond

Good PR or another bad pricing move?

If things come in three, I’m expecting another example of bad pricing policy to come my way in the next 24 hours. I just finished writing about how my shoe cobbler is leaving money on the table when along came another prime example of it.

We were out visiting last night and some friends were showing us around their $200,000 renovation project, currently under way. In the middle of the tour, my friend Harold explained how they had paid $15,000 for the design of the addition. Then he told about how his designer reduced her price by $750 after quoting on the deal, because, so she said, she had to do less drawings than she had expected.

Has this ever happened to you? After you agree to a price, the seller reduces it. Initially I thought how crazy she was, refunding $750. But then it dawned on me that this might be a brilliant move on her part. After all, she only gave up 5% of her fee, but now she has him telling his friends what an honest business person she is. Maybe she’s crazy like a fox…

I suspect that this move was not pre-meditated; his designer did legitimately over-quote, and did in fact reduce the price when she finished the job.

But as a marketer, I just can’t leave the analysis alone. I like her model for services, at least occasionally. After all, she didn’t really lose much.

What do you think? Let me know by email, or leave a comment below.

Honey, I bought the Phone. Confessions from the Cambridge Apple Store.

Alan with his iPhoneI have a perfectly good Blackberry 8200 series, but I’ve been waiting for a chance to hit the Apple store to check out the iPhone. If you’ve been reading our blog for a while, you know that we’ve been paying attention to this product launch.

Finally, a trip to Boston, over a month after the release, and here I am. In fact I’m writing to you from the Apple store in Cambridge right now. It just so happens that today is a big day for Apple; they are right now announcing a new iMac design, upgrades to iWeb, a rewrite of iMovie, upgrades to iPhoto, and several other announcements. The announcement is still under way, so the staff here is still sworn to secrecy, but I’ve been getting SMS updates on my iPhone from macrumors since the announcement stared about 75 minutes ago.

Yes, I bought an iPhone. I can only say this: the thing is truly sweet, a masterpiece of design in every way. Some people have made sensible comments, such as “It’s only a phone”, and I did actually struggle with why I had the compulsion to buy it. I decided this morning on my way over to the store that I would try the phone out and just see whether I *had* to have one. It didn’t take me long. When I picked it up, saw the slick unlock button, my reserve cracked immediately.

Now after a couple of hours of playing with it (I admit that I have been playing), I realize that while this is *just* a phone, it also somehow expresses something about my tastes in product design, ease of use, and just plain beauty.

Am I being overly romantic? Tell us what you think. You can leave your comment here, or send me an iChat …

(Saeed, I think we know how your feel. ;-) )

Now, 12 more minutes until I find out whether they have the new iMacs in stock here.

Value-based pricing

One day last week, my sandals broke. One of the straps just came undone at the seams. These were pretty nice sandals; I got them on sale for $75, but they retail at about $200 in Canada, and there were in otherwise good shape. So I decided to get them fixed.

So after work on Friday, I took them to a cobbler. I just love an old fashioned shoe cobbler; their shops often wreak of glue and polish, which makes the experience that much more authentic, and they practice a dying art of repairing things in a society that mostly just throws things away.

This guy is the real deal, and I’ve had him repair and resole several pairs of shoes for me. But this time I wanted to give him a bit of marketing advice. You see, he fixed my sandals in an hour while I sat at a nearby pub with some friends, and when I went to pick up the sandals, he only charged me $4.50.

Four dollars and fifty cents? The beer I drank while I was waiting was more expensive than that! Let’s review: this guy saw that I was getting a pair of sandals fixed on a Friday afternoon before a long weekend, realized that I would probably wear them on the weekend, offered to stop what he was doing and fix them while I waited, fixed the right sandal and reinforced the left one too, and then charged me four dollars and fifty cents.

I would have paid $15 – $20 to have these things ready for the weekend … $15 seems right, and $20 for a rush job.

I paid him $5 and told him to keep the change, and he thanked me for the tip. But I left thinking that, while I love this guy and his business, he’s leaving money on the table! I should have given him a real tip and discussed his pricing model.

Pragmatic Marketing provides a very useful 2×2 grid, with the horizontal axis being “impact” and the vertical axis “cost to implement”. My shoe cobbler was charging me based on his own costs, which were irrelevant to me. What was relevant was the impact: my $200 sandals were ready for the weekend, and would last me through another summer. The impact to me was big, but his cost was low.

We make the same mistake all the time in high-tech pricing, but rarely is the example so easy to explain. Next time my cobbler makes this mistake, I think I might give him a real tip and help him with his pricing. ;-)

How to be a GREAT Product Manager (part 4)

The 4 Cs of leadership: credibility, commitment, communication and courage

leadership2.jpgProduct managers need to be leaders. A truism no doubt. But what does being a leader really mean and how can a product manager be a great leader? Let’s start by talking a bit about authority and responsibility. Both are words related to leadership.

Responsibility: noun. a form of trustworthiness; the trait of being answerable to someone for something or being responsible for one’s conduct; “he holds a position of great responsibility”

Authority: noun. the power or right to give orders or make decisions; “he has the authority to issue warrants”

Responsibility is both a trust and a duty. Authority is something you are given or possess related to your responsibilities. The two are clearly inter-related. If you have the responsibility to do something (e.g. uphold the law), you are given the authority to do the things that need to be done to deliver on your responsibility (e.g. issue warrants).

In cases such as law enforcement, both the responsibility and the authority are explicitly defined. In the case of many business functions, particularly matrix functions such as product management, the responsibilities may be explicit, but the authority is implicit in the role. It’s up to the individual product manager to understand that and not get caught up by the lack of a hierarchical reporting structure with other teams.

In my first PM job, after a frustrating product strategy meeting with senior management, one of my fellow product managers let out the famous line:

Product Management: All of the responsibility and none of the authority!

It was the first time I’d ever heard that line, and that afternoon, I couldn’t have agreed with him more. I had faced my own battles with the CEO over product direction issues.

When the first bullet point of the first slide of your product strategy presentation quoting a well-known industry analyst is brushed off by the CEO, and the analyst called “an idiot in a monkey suit“, you know it’s going to be a rough meeting. And when the CEO regularly plays a game called “If you guess what decision I’ve made about your products, then we’ll be in agreement on that issue“, it’s hard to feel empowered.

But, in the intervening years, I’ve learned a little bit about responsibility and authority and don’t agree with that line anymore. The fact is that, regardless of whether you have a CEO (and/or management team) that “gets it” or not, you’ve got a job to do, and whatever frustration you may be feeling about lack of authority is probably shared by your peers in other teams. So what can you do to use the authority that you do have and be the leader that you must be?

Welcome to my 4Cs of Leadership.

Leadership begins with credibility.

credibility: noun. the quality of being believable or trustworthy.

If people aren’t willing to believe you and trust what you say, then there is no way you’ll be given authority to do anything significant.

How do you become credible?

For a PM, the best way is to be viewed as having the most thorough knowledge in your organization of what is needed to help make your product successful. That is what everyone is expecting of you (you are the product manager!), and if you can exceed those expectations, you will have credibility when you speak with people. Some things to put on your “How do I gain credibility?” checklist are:

  • Know your product as well as your users know it
  • Understand the architecture well enough to know it’s strengths and weaknesses
  • Talk to more customers and partners than others in your company
  • Collect more hard data about customer and market needs than your peers
  • Understand the needs and dependencies of your internal teams (sales, support, marketing, engineering)
  • Help those teams in their efforts where reasonable and valuable

Gaining credibility takes time. You’ll have a bit of a grace period when you start a new position, so use that period to get up to speed. Then, continue to work at it and ensure that once you have credibility, you don’t lose it.

The second C of Leadership is commitment. The definition I like is:

commitment: noun. the act of binding oneself (intellectually or emotionally) to a course of action

Look at that definition closely. The words are very specific: “The act of binding oneself…” You must demonstrate commitment to your product’s success. In your current job as a Product Manager, have you bound yourself to the success of your product? Or are you just going through the motions and simply doing the job? People want to see that product managers truly care about product success and figuring out what is right and best for their product. If they don’t see that commitment to success, you will quickly lose credibility.

The third C of Leadership is communication.

communication: noun. the art and technique of using words effectively to impart information or ideas.

No amount of credibility can be retained if communication barriers exist between a leader and his/her followers. Leaders must be able to communicate their thoughts, ideas, visions and strategies clearly and succinctly, and in such a way that those listening are inspired to want to be part of the plans the leader is proposing.

Note that communication is both an art and a technique. Simply conveying information in documents or in rote form is not sufficient to be deemed communication. People need to understand what you are communicating to them and realize why it is important to listen to you.

Put yourself in their position and think about what they need from you. Convey information in forms that those receiving it from you find valuable. This may mean a bit of extra work for you initially — not everyone needs (or wants) to read requirements documents — but once people see you understand their frame of reference, they’ll see the value in understanding your communications. Keep in mind, people are bombarded with information daily, and they triage what they read and what they put aside. Make sure your information gets top priority by making it easy for them to consume.

Once you have credibility with your peers, show commitment to your product, and communicate vision and details clearly, you have the hallmarks of being a leader. But what can truly distinguish a good product manager from a great one is courage.

Welcome to the 4th and most challenging of the 4 Cs.

courage: noun. to act in accordance with one’s beliefs, esp. in spite of criticism. to have the courage of one’s conviction

The difference between a leader and a manager is the leader’s ability to take risks, blaze new trails, and have people follow him or her down those trails. Leaders can be praised when they succeed, but will be criticized roundly when they don’t.

As a product manager, you are an agent of positive change in your company. Stand up for what you believe is right, but do your homework first and be able to support your positions confidently. Not everyone will take to your recommendations or initiatives, even if you are correct. But, over time change can happen, even in the most conservative or difficult environments.

In companies that are open to change, it is a continuous process. In other companies, it comes in the form of a revolution. Regardless of the type of company you work in, if you want to rise to be viewed as a great leader, then have the courage to take, as Frost put it so well, The Road Not Taken.

The last stanza of Robert Frost’s poem sums things up nicely in my mind.

I shall be telling this with a sigh
Somewhere ages and ages hence;
Two roads diverged in a wood and I-
I took the one less traveled by,
And that has made all the difference


Part 3 – “Spidey-sense” instincts are good, hard data is way better

Part 5 – Be an integrator, translator and communicator

Here’s the deal with Biz Dev (Part I)

Saeed has posted two fairly provocative items about business development. (Here are the first and the second.) Frankly, Saeed, you’re not following your own advice. To paraphrase you, “Enough with the missives about Biz Dev”.

If you’re getting annoyed by what’s going on in your company, then you have two choices — help fix it, or move on. There are a couple of other choices actually, such as do nothing, or complain about it on your blog, but to be honest, if that’s what you do, then you’re not as great a product manager as you think you are.


Certainly it’s easy to poke a stick at biz dev, and I could tell a few stories of my own. Several years ago, Intel was courting my CEO to have us port my product line to the Itanium chip, and thankfully I got to meet the Intel guy with my CEO for espresso at the old Starbucks by Moscone before we committed to anything. We were interested seeing what Intel might offer us, and my CEO really wanted to ink a deal with them. As Saeed said, it was “strategic”, and the Intel logo would look really great on our investor slide deck, or so our CEO felt. As is well known, the Itanium chip was a failure. Thankfully we didn’t invest.

In fact when we poked at Intel’s proposal, we found that the market for our product on Itanium would have been tiny; it would have been a tool to help people writing apps directly to the Intel metal, a specious group who wasn’t likely to increase our revenue. I suggested that Intel could pay a very large sum for our source code with an exclusive license on its doomed chip, but Intel didn’t bite. At that point our CEO saw that the logo on the Powerpoint slide wasn’t worth the distraction.

But I have also seen business development add major value to a company. When I was at Wily Technology, I saw how business development could be used strategically to strap a rocket to the company and create the engine for the company’s phenomenal growth. (And it was phenomenal. Eventually we were acquired for $375M, greatly exceeding the multiples of our peer group.)
What’s the difference between Saeed’s experience with BD and the Wily success story? It boils down to strategy, alignment, and value creation.

I’ll elaborate in future posts on this topic, so please stay tuned.