Building Products & Saying NO

 

Learn to say NO to the good and the advantageous, in order to receive the best!

― Sunday Adelaja

SayNo

If your Product Management team is responsible for building products, features/ideas get thrown at you – by your product team members, sales/marketing/support groups, competitive analysts, customers, partners, executives, etc. On one hand, you have the responsibility to ship a well-rounded and a well-balanced product that serves the needs of your customers. On the other hand, you have the wish list fire-hose pointed at you.

Arguably the toughest decision a Product Management team makes is – what features to include and what features to exclude. What do you build now and what do you postpone? If the goal is to offer a well-rounded product experience to your customers, I would argue that what you say NO to is more important than what you say YES to.

Rather than making ad-hoc YES/NO or NOW/LATER decisions, this blog attempts to offer an objective framework that mitigates the subjectivity in this decision-making process. This framework is based on 5 vectors of evaluation:

 

1. Utility Value & Breadth of Impact: This one is fairly straightforward. For the feature in question, ask yourself (from a customer perspective) 2 questions – (1) how useful is this feature (2) what % of my user-base will find this genuinely useful. Where possible use data to support your decisions – e.g. you could analyze your Google Analytics stats to understand how often a similar feature is being used in your existing product. These questions will help you weed out “pet projects” or cool sounding features that have little or no utility in real world.

 

2. Table Stakes: In late 90’s, much before Bluetooth and USB became popular, some computers offered IR (infrared) ports so that devices like PDAs could wirelessly connect to computers. In reality, these IR ports were rarely ever used. However, because an IR port was a common requirement in the corporate purchase checklist, most laptop manufacturers would include the IR port in their corporate class laptops even though they were rarely ever used – i.e. the IR port became table-stakes in the corporate laptop market.

Another contemporary example is the phablet product.When Samsung launched their Note phablet in 2011, it became a runaway success. Apple on the other hand, stayed away from phablets given Steve Jobs’ disdain for the large devices. Samsung Note was capturing so much market share (especially in Asia), after 3 years of resisting, Apple capitulated and launched their iPhone 6 Plus phablet in 2014 – they needed a phablet in the product lineup to stay competitive.

In your market, is the feature under consideration table-stakes based on customer requirements or competitive positioning? If so, you may no choice but to offer that feature sooner or later.

 

3. Basic VS Advanced: A few months ago I upgraded my audio receiver to a Sony DN1050 – I needed a receiver with AirPlay support. The DN1050 is a pretty sophisticated receiver that supports AirPlay, NFC, multiple zones, 4K scaling, Bluetooth, Wifi, DLNA, Pandora, Spotify, etc. BUT… it only supports 2.4Ghz wifi – no cigar with 5Ghz wifi support. Arrrgh. Why would a world class company like Sony build a sophisticated $600 consumer electronics product that relies on wifi and yet exclude 5Ghz support. My $50 Echo Dot supports 5Ghz!

This is a classic example of a somewhat disjointed product that supports sophisticated features and yet misses the basics (5Ghz wifi channel support) – that’s a head scratcher.

When building products, it’s important to cover the basics before you start considering advanced/complex features. This is a fairly simple principle and yet it eludes so many products!

 

4. ROI (effort vs benefit): Every so often you come across a feature that sounds useful – but expensive to build (in terms of time & resources). If that feature is applicable broadly, benefits a wide swath of your user-base, or gives your product a strategic edge, it may warrant making that investment. Otherwise punt it for later!

 

5. Strategic Importance: When Apple launched Siri in 2011, it was labeled as a beta. As far as I know that was the first time Apple released a feature labeled as beta (while embedded within a mainstream product) to general public. Apple knew that Siri was not fully ready for prime-time and yet they released it early on because of its strategic importance. By releasing it early and collecting anonymized voice samples, Apple was able to iterate and improve Siri over time. Now Siri is an integral part of their iOS, macOS, watchOS and tvOS.

 

Summary: For every feature/capability on the product roadmap, it’s important for Product Management teams to consciously deliberate on the YES/NO decision based on objective criteria that suit your needs (market requirements, competitive situation, strategic importance, product maturity stage, etc.). Without this deliberation, if every idea gets a YES rubber-stamp, products runs the risk of becoming a disjointed mishmash that could earn your customers wrath!

Partnerships, Product Launches & Pain Management

 

We must all suffer one of two things – the pain of discipline or the pain of regret & disappointment!

– Jim Rohn

 

partnership

 

Technology companies launch products/services using their own technology/IP. Occasionally, such products/services are launched based on a partnership between 2 (or more) companies. The nature of the partnership can vary – a partner relationship where both company names are visible (e.g. Powered By) or a white label relationship where only one company’s name is visible.

Partnerships are explored and established typically at C level with involvement from business development, finance, legal, product & engineering. Agreements are inked to settle details such as revenue share, IP ownership, product development, legal liability, customer support, marketing, etc. More often than not, deals are painted in broad strokes (and a generous measure of good faith) while the finer points are left for the product teams to figure out along the way.

Launching well rounded products is hard enough. Launching a product hinged on collaboration across two different companies and teams, the complexity & pain increases threefold because of the challenges involved around less transparency, less control, varied priorities, cultural differences, etc. This blog post attempts to put a framework around what it takes to develop & launch partnership based products/services while minimizing the pain along the way – a useful structure for product teams to ship a well-rounded product.

 

  • Functionality Brief: This is arguably the most important first step. After the deal is signed, Product Heads on both ends should work together a produce a “Functionality Brief”- a 1-2 page document (or a couple of slides) that broadly lists ALL features/functionalities that the partnership intends to deliver. It’s a simple document with one bullet per product functionality. The intent of this brief document is to broadly establish the complete scope of the deliverable – not a long MRD/PRD. The brevity of this document allows the team to see the “forest” without getting lost in the “weeds” of BRDs/MRDs/requirements.

 

  • Meeting of the Minds: While some amount of technology due diligence may have happened during the initial stages of partnership discussions, those discussions usually tend to be guarded. Now that the deal has been established, it’s time to open up the kimono and get down to brass tacks. It’s time to get the architects, subject matter experts and a couple of key engineers from both sides into a room to start whiteboard discussions on what it takes weave technologies from both ends.This sort of meeting MUST to be face to face – conference calls over Webex isn’t going to cut it. In my experience, this event works best when it happens over 2-3 contiguous days. The first day is usually spent with team members knowing each other and getting familiar with technologies on both ends. After the ice-breaker dinner & drinks together on the first night, rapport gets established & the discussions and white-boarding sessions are a lot more lucid and productive on days 2 & 3. By the end of day 2/3, product teams on both ends usually have a pretty good sense of the technology alignment and pitfalls if any.

 

  • Proof of Concept: Depending on the nature of the project & complexity, before beginning full scale product development/integration, it might be useful to do a proof of concept project. Any toxic asbestos or technology incompatibility is best discovered sooner than later.

 

  • Cross Functional Team, Roles & Responsibilities: Once a broad alignment of products/technologies has been established, it’s time to bring in the usual suspects to get the project going  – product management, engineering, QA, project management, analysts, etc. and assign clear roles & responsibilities. While BRDs, MRDs, PRDs, requirements, design documents, specs, etc. are useful to manage the execution within each function, the Functionality Brief that was developed as a first step keeps the team on the same page with regards to overall deliverable.

 

  • Customer Support: This item usually gets under estimated & ignored until much later. If company A has to provide support for pieces of product/technology from company B, it takes a non-trivial amount time and energy to get the customer support people trained. If the company A is a large global company with footprint in AMER/APAC/EMEA, the complexity gets further compounded. It’s best to involve the customer support team early on so that they can plan for training, documentation, escalation paths, etc.

 

  • DL for Communication: Create an email DL (distribution list) with members on both sides of the fence – makes it easy for everybody to communicate important details across both teams. While this may seem like a trivial tactical detail, without a DL, you can be sure that some members of the team will be dropped inadvertently on important communication and that creates a different dimension of pain (confusion, transparency, trust, etc.)!

 

  • Strong Program Manager: Given that there are 2 companies and 2 teams involved, its best to have a “stronger & savvier than usual” Program/Project manager who can deftly herd the cats while managing the scope, schedule, risks and resources.

 

  • Executive Sponsors: As product development/integration progresses, issues occasionally come up that require escalation & decision making at higher levels. Identifying executive sponsors on both ends upfront makes it easy to resolve the issues as they come up. Pick a sponsor that has the title/authority to make decisions, bandwidth to handle issues as they crop up and a temperament to work cooperatively with an external partner to resolve conflicts.

 

Delivering well rounded products based on partnerships can be painful but the above framework makes for a useful pain management!

 

Balancing Trains and Product Roadmaps

 

Balance to life is kale shakes and cupcakes!

– Joe

 

Product Train

 

Founded in 1853, the state owned Indian Railways has one of the largest railway networks in the world. With over 71,000 miles of track spanning 7000+ stations carrying over 8.3 billion passengers annually, it employs over 1.3 million people. Indian Railways generates about 70% of the revenue from freight traffic while the remaining 30% comes from passenger traffic.

Given the socialistic background of the Indian government, freight business profits are used to subsidize the passenger ticket prices so that a common man can travel very inexpensively. You could travel by train from Mumbai to New Delhi (about 900 miles) for a super low price of around $10! To enable such a low price travel, Indian Railways has to balance many variables such as freight-versus-passenger traffic, frequency, route planning, staffing levels, passenger convenience, amenities, capital expenditure, service quality, safety, etc.

In many ways, balancing train operations is very similar to balancing product roadmaps. And yet, if you look around, you will find plenty of examples of technology products (especially from big companies) that are a bit of a train wreck – uninspiring, buggy, unintuitive, slow, clunky to use, etc.

 

Why is that?

Unbalanced Product Roadmaps!

 

As companies get bigger, there is a pressure on product teams to prioritize items that have a direct ROI. While that intent is noble, it typically results in a situation where new features/functionalities are given much higher importance. Every subsequent release gets stuffed with more and more bells & whistles to appease external customers & internal stakeholders (sales, marketing, execs, etc.) and also because it’s easier to justify ROI with new features.

With this intense focus on new features & functionality, 2 things usually get the step-child treatment:

 

  1. Infrastructure Improvements: Every technology product has frontend/backend infrastructure like databases, middleware, messaging, caches, security framework, identity management, UX frameworks, analytics, test automation, etc. Keeping this infrastructure humming takes a non-trivial effort on an ongoing basis. And yet, such infrastructure improvements typically take a back seat because improving/maintaining it is not as sexy as product bells & whistles.
  2. Refinements: This is polishing the product to a shine – bug fixes, performance improvements, UI/functionality tweaks, usability improvements, etc. It’s the little details that elevate the product experience. Again, this area typically doesn’t get much love.

 

Over a period of time, as the products get stuffed with more and more bells and whistles with little attention to Infrastructure Improvements and Refinements, the product becomes clunky. Technology industry even invented a term “technical debt” to describe this. It’s a fancy way of saying “we didn’t do stuff that we should have and we kicked the can down the road”.

 

What’s the mantra to prevent that?

Balanced Roadmaps!

 

When planning product roadmaps, management should mandate product teams to present a balanced roadmap. Every product release should offer a balance of Features and Functionalities, Infrastructure Improvements & Refinements:

 

Balanced Product Roadmap

 

Typically, I guide my teams to allocate about 60% of the bandwidth to Features and Functionalities, 20% to Infrastructure Improvements & the remaining 20% to Refinements. While this allocation can vary, in the long term, this structure allows product teams to deliver solid well-rounded products in a disciplined manner without incurring “technical debt”!

Methodically Ignoring Your Customers, Again?

Customers are like teeth. Ignore them and they’ll go away!

– Jerry Flanagan

 

Ignored Customer

 

You read that right! Many medium/large sized companies in Corporate America have processes that methodically (but unintentionally) ignore the customer – especially in the software technology space. Here is what I mean…

Consider a medium/large sized company Acme Corporation that is in the technology business (my domain). When the product teams (comprised of Product Managers, Eng, QA, UX, Marketing, etc.) plan the next big version of the product, they seek input from key stakeholders. Sales teams provide feedback on new features/functionality that lets them close more deals. Customer Support provides input to improve product quality & reduce support contact thereby bringing cost savings. Marketing provides competitive information and other inputs to better position the product against competition. Different stakeholders provide inputs that impact their groups. So what’s missing?

What about your existing loyal customers who religiously use your product/service’s existing functionality? These loyal customers are your bread and butter. Chances are, they are being methodically ignored during every product cycle – here’s how:

When existing customers or prospects request new features that are deemed “major”, such requests are usually acted upon. If customers complain about egregious problems, they get fixed. What about problems that are “minor” inefficiencies, irritations or improvements? Often customers don’t proactively complain about what they see as “little issues”. Even if they complain, often that feedback gets lost in the process because those issues are prioritized as “minor” and get ignored. Over a period of quarters and years, these “minor” product issues accumulate and the end result is a product that’s heading towards mediocrity.

Why does this happen?

Engineers want to work on cool new stuff. Product teams are pressured into working on items that affect the sales top line or cost savings bottom line. Items that make the teams look good in QBRs (quarterly business reviews) get a higher priority. Egregious problems do get fixed, while the “minor” issues/irritations/improvements often get ignored. As a result, without the product teams realizing, the product gradually creeps towards mediocrity.

Don’t believe what I am saying? Take a look at your company’s HR, Procurement, Contract, Inventory, Quoting, Payroll, Legal or such similar software. Barring an exception or two, chances as, these products have mediocre user experiences (clunky, un-intuitive, hard to use, missing functionality, etc.).

How to avoid this march to mediocrity?

There’s at least 3 ways to monitor & address this.

  1. Measure Customer Satisfaction: Senior Management needs to actively drive the exercise of bi-annual (or annual) customer satisfaction measurement. NPS (Net Promoter Score) is an industry standard methodology of measuring how likely your customers are to refer your product/service to others. NPS is a direct reflection of customer satisfaction. Management needs to measure NPS (or an equivalent metric) on an ongoing basis and make this score a part of the KPI (key performance indicator). This gives an incentive to product teams to pro-actively address the minor issues.
  2. User Research: Most companies under invest in user research – read more on this here. When user research investments & activities are increased, product/service niggles are uncovered that can be then proactively addressed by the product teams.
  3. Dedicate Bandwidth: Product teams should dedicate a non-trivial percentage of engineering bandwidth (e.g. 10% – 20%) and use this bandwidth to exclusively focus on improving existing product functionality (not new functionality). This forces product teams to proactively address  “minor” issues & details that often get swept under the rug. Click here to read more on the topic of little details.

 

None of this is rocket science. It’s a matter of Management and Product Teams deliberately setting priorities and allocating investments & resources to make sure that customers and products experiences are not getting ignored!

 

Silicon Valley Engineering VS Wall Street Engineering

I think one problem we’ve had is that people who are smart, creative and innovative as engineers went into financial engineering.

– Walter Isaacson

 

FinancialEng

What do Citrix & Yahoo have in common? Along those same lines, what do Facebook and Google have in common?

These companies typify the battle that’s brewing between Silicon Valley Technology Engineering & Wall Street Financial Engineering!

Since the early days of Silicon Valley with Shockley Semiconductor, Fairchild Semiconductor and Intel, our tech industry has been intertwined with venture capitalists & wall street. Technology companies need access to cash to fund the engineering efforts. VC’s are only too happy to supply the funds in hope of future payoffs. When that payoff happens in the form of an IPO, Wall Street too gets their pound of flesh. Over the years, asset management companies, LBO specialists, investment bankers, hedge funds & private equity funds too got involved in the game by investing in private & public companies, taking the public companies private, buybacks, special dividends, divestitures, spin-offs, mergers, etc. – quite a financial engineering bouquet.

In the recent years, beyond writing investment checks, some of these funds have been taking a more aggressive stance in dealing with the tech companies that they have invested in. Initially, they try to work behind the scenes with the company’s management team to drive the changes they seek. If that doesn’t work, they lobby & fight publicly (open letters to management, proxy wars, board room battles, lawsuits, etc.) to drive changes – hence the term “activist investors”.

Yahoo: Yahoo has been going through a turmoil in the recent years – revenue/profit drops, lack-luster product strategy, non-performing acquisitions & “acquihiring”, losing market share, talent exodus, competing with Google, Facebook & Microsoft, etc. Clearly, the investors who plunked money into Yahoo aren’t too thrilled. Hedge fund investors like Starboard Value are openly pushing for major changes such as selling Yahoo’s core business, layoff employees, replace executive management, etc.

Citrix: Meanwhile, Citrix has been facing its own share of pressure from its activist investor Elliott Management. Driven by Elliott, Citrix has been divesting product lines, spinning out its GoTo products, laying off employees, etc.

These moves on the part of activist investors are designed to improve the company’s stock value & EBITDA multiples in the short term – leading to a higher ROI for the investors. However, these activist investors are probably not thinking about the long term impact on the company, employees, product strategy, synergies, customers and partners. These investors have a single minded drive of improving short term ROI and nothing but ROI – and it’s hard to fault them because that’s how the Wall Street gets compensated.

So, how are companies supposed to protect themselves from these short term ROI driven investors? How do they control their destiny?

Turns out, Facebook and Google have figured that out!

Facebook: Facebook instituted a dual-class stock structure years before the IPO – class A & class B shares where class B shares carry ten votes per share while class A shares carry one vote per share. Mark Zuckerberg owns class B shares while the rest of the mere-mortals gets class A shares. As of few months ago, Zuckerberg controls 55% of the voting power even though his share ownership is much lower. What this means is – Zuckerberg and his team have absolute control over the company strategy & direction. Investors and Funds have no ability to hold the gun to Zuckerberg’s head or do any financial engineering to drive short term ROI!

Google: Google being Google (aka Alphabet), takes this strategy one step ahead of Facebook. Google has a three class share structure – classes A, B & C. Class A shares (ticker:GOOGL) get one vote per share, class B shares get 10 votes per share while class C (ticker:GOOG) shareholders get zilch/zero/nada votes per share. Class B shares (with 10 votes per share) are owned by Larry Page, Sergey Brin, Eric Schmidt and a few other insiders. This structure puts Google’s reins firmly in the hands of the management team without any form of activist investor interference. This absolute control also makes it easier for Google to spend billions of dollars on the moonshot projects without having to worry about the second guessing investors!

While its reassuring to know that the likes of Mark Zuckerberg, Larry Page, Sergey Brin & Eric Schmidt have absolute control over their company’s destiny, over the long term, only time will tell whether that’s a good thing or not!

 

Apple TV – 4th Time’s the Charm for Industry Disruption?

If it weren’t for Philo Farnsworth, inventor of television, we’d still be eating frozen radio dinners.

 – Johnny Carson

 

Apple TV Small

 

Apple debuted the Apple TV product over eight years ago in Jan 2007. Over the years, Apple introduced 3 generations of the Apple TV to lukewarm response. Perhaps this lack of success is what prompted Steve Jobs to position the Apple TV as a “hobby”. The go-to market challenges associated with regionalized cable operators, hard negotiating oligopolistic studios, mish-mash of government regulations, consumers’ unwillingness to pay for a set top box, etc. certainly did not aid innovation in this industry.

For 8+ years Apple kept honing the Apple TV “hobby” and released their 4th gen New Apple TV a couple of weeks ago. In the latest iteration of the Apple TV with its new-fangled tvOS, Apple finally did a copy-paste of the AppStore ecosystem from iOS onto the TV. That opens the innovation flood gates of 3rd party developers to let a “million flowers bloom” for the TV experience. My fingers raced to click the Buy button on the first pre-order day!

I am not going to bore you with yet another review of the product – you can find that on NY Times, CNET & Engadget. Instead, here is my take on Apple TV’s potential (and Android TV, see PS below) to change & disrupt a few industries:

 

Casual Gaming: For the first week of the launch, Apple prominently featured the Asphalt 8 game on its TV AppStore. When my 11 year old son saw the Asphalt 8 icon on the TV, his eyes lit up and his jaw hit the proverbial floor. For the next hour, I could not pry the Apple TV remote from his hands while he raced his tricked out & nitro’ed McLaren P1 GTR through the streets of the London while the home theater speakers pumped out the visceral chest thumping roar of the McLaren. Quite a sensory experience that you don’t get on iPhones and iPads! Apple deliberately invested quite a bit on their graphics and game development frameworks/SDKs to make this possible.

While these $2.99 tvOS games may not be a threat to billion dollar franchises like Halo, the landscape of the casual gaming industry (think sub $20) will definitely change. In the coming years, the publishers of lightweight games on the game consoles will have a hard time convincing their customers to pony up $10-$20 for a game console title while similar games can be had on a multi-purpose Apple TV for $1.99 – $4.99. Over time, I expect these game publishers to migrate to the Apple TV gaming platform (& Android TV, see PS at the bottom).

 

Online Learning: After dinner, when the family has gone off to sleep, I have some difficult choices to make – read, watch Netflix from the comfort of a sofa or do something productive & cerebral with the laptop. It’s hard resisting the siren song of the sofa & remote!

With apps like TED & Coursera on the New Apple TV, it’s easier to engage in something more cerebral while comfortably ensconced in the sofa. Suddenly the Machine Learning course in Coursera doesn’t seem as daunting as it does on the computer. Given this ease of learning from the sofa & the TV, I expect more consumer traction for the online learning industry on the TV.

 

Cable TV Industry: This is going to take a few years to play out. Barring the exception of Tivo and DVRs, the cable TV experience has been more or less static for the last few decades. An average American household pays $86/month for cable TV – for which you get a few hundred channels most of which you never watch. With the availability of HBO, ABC, National Geographic, Disney etc. in an ala-carte model on the Apple TV, cord-cutting is now easier than ever before. However, before TV consumption over IP becomes mainstream, a lot of work needs to be done by Apple to improve the user experience. The current model of app switching on the TV is nowhere as convenient as channel surfing with your set top box!

This decoupling of content providers & cable operators probably bodes well for the content providers as well. Once they have their channel as an app on the Apple TV (or Android TV), their market availability is worldwide – they probably don’t need to worry about negotiating with dozens of cable operators worldwide!

 

What other Disruptions?: Unlike mobile phones, tablets and laptops that offer a personalized compute experience for you, an app-enabled smart TV offers a new model – a shared (for you & everybody around you) compute experience from the comfort of a sofa. Try the gorgeous AirBnB app on a TV and you will know what I mean. The voice search via Siri is also pretty nifty – I’m looking forward to Apple opening up Siri to third party developers. What new opportunities (or disruptions) that creates, only time will tell. I for one, am quite looking forward to that!

 

PS: The New Apple TV & Google’s Android TV are very similar positioned and compete neck to neck. Given that, the above commentary applies equally well to the Android TV. In fact, the combined forces of these 2 behemoths probably double the chances of industry disruption!

Hire the person that says – “I Don’t Know”

Time spent on hiring is time well spent!

– Robert Half

Hiring

Over the years, I have interviewed and hired (& sometimes fired) many people – including engineers, product managers, QA, marketers, project managers, senior leaders, etc. Whether it’s a startup or a multinational corporate, hiring is arguably one of the most important decisions for the company.

So, how to hire the right people for the job? How to separate wheat from the chaff? Here are a few things I look for when I interview & hire people:

Domain Knowledge: Whether you are running a refrigerated meat warehouse or building a Cassandra big data warehouse, unless you are hiring fresh grads, you need to hire people who have an understanding of your business, technology involved, industry knowledge, etc. Hiring people with the right domain knowledge mix allows you to build the correct product/service with fewer mistakes & iterations. There is a reason why companies like Apple, Google, Facebook, Netflix, Yahoo, Microsoft, Tesla, etc. pay premium salaries & sign-on bonuses while poaching from each other to get the domain expertise.

Basic Smarts: Don’t think I need to elaborate much on this.

Tenacity & Persistence: Great products/services don’t built in the first iteration – similarly tough problems don’t get solved in the first try. You need to keep going at it until you crack it. I look for evidence in the person’s resume/background that shows that the person has the persistence to keep going even when things get tough.

Details & Execution Strength: As they say, success is 1% inspiration and 99% perspiration. I like people who are willing to sweat the details and focus on execution (aka get stuff done) – I’m not a big fan of people who skim the details. If you don’t dive into details, whatever you deliver will be pedestrian quality that will crumble sooner or later. When Mark Hurd got fired from HP, he immediately got hired by Oracle with a $40 million pay package. Why? Mark had a reputation for detailed analysis and focus on driving results. Read more about my views on attention to details…

Thinking Patterns: I like to understand how the candidate structures his/her thinking on a given topic. To judge this, I sometimes ask candidates to share a non-confidential document/deck that they have authored. This also helps me gauge their communication skills.

Team Composition & Culture: You need to ask the question – how does this new person fit into the overall team composition? People-person vs lone-wolf, tactical do’er vs strategic thinker, leader vs follower, specialist vs generalist, academic vs hustler, etc. End of the day, what you want is a well-balanced and a well-rounded team that gets the job done.

… and now about that rare quality:

I Don’t Know: Professional and Intellectual honesty is one of the most under-rated qualities – it’s also a quality that’s hard-to-detect. Everything else being equal, when I find a smart candidate that says “I don’t know” for a question or a concept, I know I have found an intellectually honest candidate. This also affirms that the candidate is not a glib talker.

Hiring right is more of an art than science – hope you find the Yoda you’re looking for!