AKF Partners

Abbott, Keeven & Fisher PartnersPartners In Hyper Growth

Guest Post – Effective CTOs

The following guest post comes from long time friend and former colleague Michael “Skippy” Wilson.  Michael was one of eBay’s first employees, and its first CTO.  He was responsible first for taking “eBay 1.0″ (Pierre Omidyar’s PERL scripts) and converting them into the modern site written in C with which most people are familiar.  He and his architecture team subsequently redesigned the site with multiple service oriented splits (circa 2000) to enable it to scale to what was then one of the largest transaction sites on the internet.  There was no “playbook” back then for how to scale something as large as eBay.  Michael was one of the early CTOs who had to earn his internet PhD from the school of hard knocks.

Effective CTOs

The excellent blog post This is How Effective CTOs Embrace Change talks about how Twilio CTO Evan Cooke views the evolution of a CTO through a company’s growth.

While this article does an excellent job of identifying the root causes and problems a CTO can run into in– especially working with his fellow C-Level colleagues – I think there is another problem it does not address.

Ironically, one of a CTO’s biggest challenges is actually technology itself and how the CTO manages the company’s relationship to it. These challenges manifest themselves in the following ways:

Keeping appropriate pace with technological change

When a company is young, it’s agile enough to adopt the latest technologies quickly; in fact many companies change technologies several times over as they grow.

Later, when (as the article says) the CTO starts saying “No” to their business partners, they may also react to the company’s need for stability and predictability by saying “No” too often to technological change.  It only takes a good outage or release slippage, triggered by some new technology for the newly minted CTO to go from being the “Yes” man to the “No” man, sacrificing agility at the altar of stability and predictability.

The same CTO who advocated changing languages, database back ends, and even operating systems and hardware platforms while the company was growing finds himself saying “No” to even the most innocuous of upgrades. While the initial result may be more stability and predictability, the end result is far from that: the company’s platform ossifies, becomes brittle and is eventually unable to adapt to the changing needs of the organization.

For example, years ago, before the domination of open-source Unix variants like OpenBSD and Linux, many companies “grew up” on proprietary systems like Solaris, Microsoft, and AIX, alongside database counterparts like Oracle, and Sybase.  While they were “growing up” open source systems matured, offering cost, technology, and even stability benefits over the proprietary solutions. But, in many cases, these companies couldn’t take advantage of this because of the perceived “instability” of these crazy “Open Source” operating systems. The end result was that competitors who could remain agile gained a competitive advantage because they could advance their technology.

Another (glaring) example was the advent of mobile. Most established companies completely failed to get on the mobile bandwagon soon enough and often ended up ceding their positions to younger and more agile competitors because they failed to recognize and keep up with the shift in technology

The problem is a lot like Real Life ™. How do you continue to have the fun you had in your 20s and 30s later on, when things like career and family take center stage? Ironically, the answer is the same: Moderation and Separation.

Moderation means just what it says: use common sense release and deployment planning to introduce change at a predictable – and recoverable – rate. Changing to a new database, a new hardware platform, or even a new back end OS isn’t a big change at all, as long as you find way to do it in an incremental and recoverable matter. In other words, you can get out of it before anyone notices something went wrong.

Separation means you build into the organization the ability to experiment and advance all the time.  While you front end production systems may advance at a mature pace, you still need to maintain Alpha and Beta systems where new technologies can be advanced, experimented with and exposed to (willing) end users. By building this into your organization as a “first class” citizen, the CTO keeps the spirit of agility and technological advance alive, while still meeting the needs of stability and predictability.

Making sure Technology keeps pace with the Organization

The best way to describe this problem is through example: Lots of today’s start-ups are built on what are called “NoSQL” database platforms. NoSQL databases have the advantages of being very performant, in some cases very scalable, and, depending on who you ask, very developer friendly. It’s very clear that lots of companies wouldn’t be where they are without the likes of MongoDB and Couchbase.

But, as many companies have found out, not all NoSQL solutions are created equal, and the solution selected in the company’s early years may not be appropriate as the company grows and it’s needs change.

For example, as the organization matures, parts of the organization will start asking for reports, they may find that while their NoSQL solution worked well as an OLTP solution, it doesn’t work as well for OLAP or Data Warehousing needs. Or, a NoSQL solution that worked well for warehousing data, doesn’t work as well when you give your customers the ability to query it on-line, in an OLTP-like fashion.

This can occur when the CTO isn’t able to help guide the company’s technology forward fast enough to keep pace with the changing organizational needs. Unfortunately, if the problem reaches the “critical” stage because, for example, the organization can’t get reports, the solution may become a politically charged hack job instead of a well-planned solution.

Every organization – engineering, database administration, operations, etc, will want to “solve” the problem as quickly as possible – so while the end solution may solve the immediate problem, it probably won’t be the one you’d choose if you’d planned ahead.

The solution here is for the CTO to continuously engage with the Company to understand and anticipate its upcoming technology needs, and engage with Engineering organizations to plan for them. It’s actually better for the CTO to arrange to engage the stakeholders and engineering organizations together rather than serially: it encourages the stakeholders to work together instead of through the CTO.

Making sure Technology keeps pace with Security requirements

Today’s engineers have an amazing community of Open Source Developers and Tools to draw on to get their work done.

And when a company is growing, tools like NPM, grunt, brew, and Hadoop are amazing tools. In many cases, they enabled development to move exponentially more quickly than they could have otherwise.

Unfortunately, many of these tools are gigantic security risks.  When an engineer types “grunt install” (a node-related command), or “brew update”, do they really know exactly it is doing? Do they know where it’s getting the update? Do they know if the updates can be trusted?

They don’t. Let’s not even going to go into the horrors they’re inadvertently inviting behind your firewall.

The problem for the CTO is that they probably had a hand in introducing these tools and behaviors to the organization, and will now be faced with reining them in. “Fixing” them will probably make them harder for engineers to use, and feel like a hassle instead of a common-sense security measure.

The CTO can expect the same situation when charged with guiding the organization towards things like always-on HTTPS, better encryption-in-place of customer data, etc. Not only will they have to convince their engineering organizations it’s important, they may also have to convince the rest of the organization that these measures deserve a place in line along with other product features.

One solution to this is a backward-looking one: Security should be part of the product and company’s culture from Day 1.  Not just protecting the company’s assets from unauthorized access, but protecting the customer’s assets (data) just as vigilantly. A culture like that would recognize the two examples above and have either solved them, or be willing to solve them quickly and without easily without politics getting in the way.

If the CTO’s organization wasn’t built that way, their job becomes much harder, since they now need to change the company’s culture. Fortunately, recent events like the Sony hack and Snowden’s revelations make this much easier than it was 2 years, or even a year ago.

Conclusion

The effective CTO faces at least two challenges: Becoming a effective part of the company’s executive team (not an “outside advisor”), and an effective part of the company’s technology and product teams. The CTO can’t forget that their job is to continue to keep the company on the appropriate forefront changing technology – far enough ahead to keep pace, but not so far ahead as to be “bleeding edge”. Almost universally the way to do that is to make technological change part of the company’s culture – not a special or one-off event.

–Michael Wilson

Send to Kindle

Comments Off on Guest Post – Effective CTOs

Just for Fun – The Many Meanings of “I Don’t Disagree”

OK.  Who was the knucklehead who thought up the ridiculous corporatism of “I don’t disagree”?

Seriously.  What does this mouth turd even mean?

Does it mean that you simply don’t want to commit to a position?  Do you need more time to determine a position?  Is your ego too large to admit that someone else is right?  Do you really disagree but are too spineless to say it?  Were you not listening and needed to spout some statement to save face?

We owe it to each other to speak clearly, to engage in meaningful dialogue about important topics, and to convey our thoughts and positions.  When political correctness overrides fiduciary responsibility, we destroy stakeholder value.  Get rid of this piece of mouth trash from your repertoire.

Send to Kindle

Comments Off on Just for Fun – The Many Meanings of “I Don’t Disagree”

DevOps – Not Good Enough

DevOps is a grassroots movement born from the passions of practitioners dissatisfied with the cultural and functional deficiencies endemic to functionally oriented (aka silo’d) organizations. The tools these practitioners employed and developed including Chef, Vagrant, Juju, Hudson and Logstash (to name a few) codified their collective feelings of how development and operations could work better together. These pioneers in effect duct taped together the development and operations teams – covering a chasm characterized by differences in culture, goals, leadership, philosophies, and toolsets. This technological equivalent of a “redneck” fix has been successful, but it is also time to see it for what it really is: the treatment for a symptom of the underlying outdated organizational concepts. For all that DevOps provides it cannot treat the many other symptoms of suboptimal organization construction. These include low levels of innovation, higher than necessary levels of conflict, and slower than necessary time-to-market. Why continue to duct tape together a poorly designed system? It’s time to replace the broken system and its temporary repair with one that works.

DevOps1

A functionally aligned technology group is a biped with a foot planted in two disjointed pasts, neither of which have a future in modern online products. One “foot” is planted in the world of corporate IT, where hosting platforms and enterprise architectures were defined to allow heterogeneous third party systems to coexist in a single, cost effective and easy to manage environment. Because IT is typically considered a cost center, the primary driver year-on-year is to reduce cost on a per employee basis. One way to do this is to standardize on infrastructure and require that third party providers conform to corporate standards – shifting the burden of cost of integration to those third party providers. Hence was born the traditional infrastructure and operations groups found within today’s technology organizations. These organizations and their solutions are awesome if you are integrating third party solutions – they are the last nail on your coffin if you are developing a product.

DevOps4

The other “foot” is planted in the past of packaged or “on-premise” software providers. In this past (heavy emphasis on the past), the software developer was king. Job one was to produce software that customers would buy. Forget about running it – who cares – that’s someone else’s job. In this past there was no infrastructure team. We just eat requirements and poop software. Sales engineers and systems integrators are responsible for figuring out how to shoe horn generic software into a wide variety of customer environments. As archaic and dysfunctional as this approach sounds, it actually worked because there was alignment between what the producing company created (software) and what the purchasing company bought (software). But it doesn’t work anymore because no one buys software. Get over it.

DevOps5

Today customers buy SERVICES not software. The mindset shift necessary to be successful in this new world is that the raw materials comprising these services are equal parts software and hardware (infrastructure). If your team doesn’t combine these raw materials purposefully, the resulting service won’t be as good as it should be. Continuing to “produce” software and “host it” on infrastructure is a recipe for suboptimal results at best and a possibly a disaster.

DevOps3

It’s time to move on from both functional organizations (e.g. Operations, Infrastructure, Software, QA) and the DevOps solution that duct tapes them together to organizations that can more easily design, implement and deploy these services. Organize your teams into cross-functional, experientially diverse, autonomous teams that own distinct services within your product. Each team and service should be driven by business focused KPIs. These teams should be self-sufficient enough to develop, deploy, and support their service without having to rely on other teams.

DevOps2

We understand this leap isn’t easy, and we are here to help. To be successful you must evolve both your architecture and your organization such that the two are compatible. In so doing, our clients experience higher levels of innovation, faster time-to-market, and lower levels of conflict than those that adopt a DevOps only duct tape solution. We call this approach to organizing the “Agile Organization”.  To help our clients evolve to experientially diverse teams, we often introduce as a starting point a concept that we call “GrowthOps”.  GrowthOps differs from the traditional DevOps approach in that it starts with an understanding of the desired outcomes of a product in terms of business KPIs (key drivers of growth for instance).  Rather than trying to duct-tape organizations together, we start by aligning disparate organizational objectives and focusing on customer value creation.  We then add in all of the tools necessary to speed time to market and monitor core KPIs.  This unique approach establishes a firm foundation for a company to grow – be that growing from on-premise to SaaS, growing from collocation centers into the cloud, or growing because of customer demand – and allows for an easier subsequent transition to the Agile Organization.

DevOps6

We love duct tape as much as the next person but it’s time organizations stopped using these types of solutions and get to the real root-cause of the friction between development and operations. Only by embracing the true root causes and fixing the organizational issues can teams get out of their own way and grow effectively.  Implementing GrowthOps as a first step and ultimately transitioning to the Agile Organization is a proven recipe for success.

Devops7

Send to Kindle

Comments Off on DevOps – Not Good Enough

Product Management Excellence

While not technical problem solvers, Product Managers arguably have the most difficult job in modern software development. Their core mission involves taking feedback from a diversity of sources (market trends, the business owner’s vision, the competitive landscape, customer complaints, feature usage statistics, engineering effort estimates) and somehow synthesize all these inputs into a single coherent vision (roadmap) and prioritized task list (product backlog). If that weren’t challenging enough by itself, they’re also on the hook for articulating feature implementations (through user stories and daily discussions with engineers) and for continually providing forecasts of feature release dates. (Btw, If anyone needs to know AKF’s position on whether or not you need dedicated full-time PMs read here.)

Given the difficulty of the task, it’s not surprising that many product owners fall short of excellence. In the worst cases, what was envisioned as a stream-lined agile development process devolves into waterfall by another name. Product sees developers as “ticket-takers” who can’t seem to work hard enough or fast enough to satisfy the wants of the business. To prevent this sort of downward slide into mediocrity and to keep your product management practices on point, below we’ve highlighted some key ways to differentiate a Great Product Manager from just a “Good” one.

Good Product Managers prioritize their backlog and communicate feature requirements through user stories and face-to-face discussions with engineers. Great Product Managers go beyond these core tasks and participate in Product Discovery and Product Validation. Product Discovery requires conducting market research to determine what the existing product might need to be (more) successful in the target market. This means watching market trends, tracking competitors, and keeping overall sense of where the competitive landscape is headed. Product Validation is quantifying the results of a feature release, asking if these met expectations, and learning how to make better predictions in the future. The very best PM’s establish “success metrics” for each and every feature prior to implementation.

Good Product Managers interact daily with their agile team. Great Product Managers are part of the agile team. They’re not simply interacting on an “as needed” basis; they’re an integral part of the agile process. They attend daily stand-ups and retrospectives, offer ideas on how to change course, and communicate continually with engineers about tradeoffs. They don’t just write a user story, they discuss the story with developers and test engineers to ensure everyone has a common understanding of what’s being built. If the Agile Team fails to deliver on time — or worse yet, builds the wrong feature — they own a part of that failure. If the Agile Team delivers a great release, they share that success with their teammates.

Good Product Managers prioritize new features that generate the greatest value to the business. They understand technical debt and aim to pay it down over time. Great Product Managers do all this, but also recognize that product management isn’t just accretive. It’s not about just about heaping feature after feature on your product until it’s saddled with bells and whistles. Great Product Managers put themselves in the end-user’s seat and choose to refactor, merge, or deprecate features when it makes sense to do so. Eliminating unused features helps to minimize technical debt. This feature selection process improves the maintainability of the code and gives end-users a clean interface that balances functionality and ease of use.

Good Product Managers avoid making mistakes. Great Product Managers recognize and retain a memory of mistakes and past failures. It’s all too easy to brush failed ideas under the carpet. Great Product Managers recognize this and choose to capitalize on their failures. They learn from mistakes and vow never to repeat them. They keep bad product ideas from being recycled and keep their teams focused on generating value.

Finally and most importantly:

Good Product Managers say “Yes” to ideas that create value to the business. Great Product Managers say “No” early and often to all but the most valuable ideas. You see, the problem most SaaS companies face isn’t a lack of ideas, but finding a way to identify the most promising ones and prioritizing them correctly. Keeping the team focused on delivering value requires the Product Manager to dish out a lot of ‘No’s to tasks that might steal from the team’s time.

It’s your engineering team’s job to build your product right, but your Product Manager is there to ensure that you build the right product. Building the Taj Mahal is no good if the customer really needed the Eiffel Tower! By no means is it an easy job, but by adopting these best practices your Product Managers can achieve excellence.

Steven Mason
Consultant, AKF Partners

Send to Kindle

The AKF Story

Tom Keeven came up with the idea for AKF Partners in December 2006. Each of the founding partners would spend a handful of days a month helping interesting companies with their technology challenges. It sounded like the perfect “lifestyle/retirement job” – help fun companies solve challenging problems while having lots of time on the side for personal projects. AKF was born in February of 2007 with 3 founding partners. When we founded the company in February 2007, we had no engagement model and no unique or differentiating approach for the business. Essentially, our company violated everything we had learned in business school.

Our Defining Moment

One early client stands out as helping us to create our unique and differentiating approach as a growth consulting firm. This company was a post-A series internet startup that had recently run into some fairly serious product problems. The company was the darling of the internet, and their CEO was being talked about in nearly every magazine. The executive team proudly proclaimed that they had a new management approach – one that would change the way companies were managed forever. But what the company thought was novel, we felt was contributing to their problems; the lack of management discipline was allowing product problems to linger unsolved and causing significant issues for the users of their product.

An example that everyone can probably relate to, whether you’re a weekend warrior or seasoned athlete, is a strained or torn muscle.. If a doctor prescribes pain medication, the meds will help treat the symptom of the problem (the pain) but they will neither address the cause of the incident (improper form) nor treat the cause of the pain (tear or inflammation). This early client made it clear that they only wanted our pain medication – technical fixes to the problems they had encountered to date. While we were happy to give them the advice they wanted, we also felt obligated to address the causes of their pain. We told the client if they wouldn’t listen to all of our advice, including how they should manage their team and which processes they should implement, we would leave and not charge them. The client could have the technical recommendations we had already made for free.

AKF’s Focus and Approach

From that moment on, AKF focused solely on client value creation. We believe that creating value for our clients will result in the best possible outcomes for our company. We’ve since told many clients that we won’t work with them if we believe they won’t take our advice. We aren’t simply drug peddlers or professional consultants whose primary goal is to sell more consulting. We provide pain relief in the form of architectural advice and injury avoidance through advice on organizations and processes.

Realizing that our approach of evaluating architecture, organizations and processes was unique within the industry, we wrote our first book, The Art of Scalability, to help clients who couldn’t directly afford onsite services. The book was an Amazon bestseller and now has over ten thousand copies sold. We subsequently wrote Scalability Rules, a companion to The Art of Scalability and a third book, The Power of Customer Misbehavior, which explores the attributes of successful viral products and the companies that build them. Together, these books help teach companies how to drive growth within a market, and service that growth within their products.

We successfully followed this approach of treating both the symptoms (architectural/technology pain) and causes (people, organizations, management and processes) through hundreds of clients until the Healthcare.gov debacle of 2014.

Putting Our Values to the Test

Upon launch, the healthcare.gov website supporting the Affordable Care Act simply could not keep up with user demand and repeatedly crashed. People attempting to sign up for government mandated insurance could not comply with the law. For many companies in our business, this would represent an incredible revenue opportunity. We saw it as an opportunity to help and continue our service to our nation.

The founders of AKF are neither registered democrats nor huge proponents of the Affordable Care Act. That said we do believe that expensive initiatives should fail or succeed based on their merits and not die as a result of easily avoided technical failures. When Jeff Zientz, who was appointed by the President to “fix” the ACA called on AKF asking for help, we agreed as long as we were allowed to contribute to both the technology symptoms and the organizational, management and process causes. We suggested that we do all of these things on a pro-bono basis such that taxpayers could sign up for healthcare in compliance with the law.

True to our past experiences with other clients, the technology failures were a result of poor management practices, a lack of coordination processes, and a failure to quickly address the root causes of early technical symptoms. And true to the principles and values of our company, we worked to help create client value (in this case some return on tax payer investment). To us, it was unfathomable to charge a fee for what was already an over-priced solution.

The Past and the Future

The early, unnamed startup (which has since gone out of business) and ACA examples are extremes in our experience. Very few of our clients display the complete lack of management or absence of processes that these examples represent. For most of our clients, simple tweaks pay incredible dividends. Most clients are staffed by hard working and focused people who suffer from the same tunnel vision we’ve personally experienced in our past jobs. Rising above the chaos of explosive growth is difficult. Having a partner can help force companies to make the time to consider their options. We approach every company as though we are extensions of that company’s team, helping to guide the team and leverage their and our combined experience to design the most appropriate solution. Most importantly, we never take on a client without believing we can help them create more value than what they’ve spent on our services. In eight years AKF has worked with hundreds of clients and grown from three individuals working part-time to twelve fulltime people, with still more to be hired in 2015. We continue to grow because we provide value to clients by identifying the true root causes of issues, not just quick technical patches.

Send to Kindle

1 comment

Selecting Metrics for Your Agile Teams

One of our favorite sayings is “you can’t improve that which you do not measure.” When working with clients, we often emphasize the need to select and track performance metrics. It’s quite surprising (disheartening really) to see how many companies are limping along with decision-making based entirely on intuition. Metrics-driven institutions demonstrably outperform those that rely on “gut feel” and are able to quickly refocus efforts on projects that offer the greatest ROI.

Just as your top-level business KPIs govern strategic decision making, your agile teams (and their respective services) need their own “tactical” metrics to focus efforts, guide decision making, and make performance measurable. The purpose of agile development is to deliver high quality value to your customers in an iterative fashion. Agile facilitates rapid deployment, but also allows you to garner feedback from your customers that will shape the product. Absent a set of KPIs, you will never truly understand the effectiveness of your process. Getting it right, however, isn’t an easy task. Poorly chosen metrics won’t reflect the quality of service, will be easily gamed, or difficult to track, and may result in distorted incentives or undesirable outcomes.

In contrast, well-chosen metrics make it simple to track to performance and shape team incentives. For example, a search service could be graded against the speed and accuracy of search results while the shopping cart service is measured on the percentage of abandoned shopping carts. These metrics are simple, easy to track, difficult to game, and directly reflect the quality of service.

Be sure to dedicate the time and the mental energy needed to pick the right metrics. Feedback from team members is essential but the final selection isn’t something you can delegate. After all, If I’m allowed to pick my own performance metrics — I can assure you I’m always going to look awesome.

To keep you on the right track, below is a checklist of considerations to take into account before finalizing the selection of metrics for your agile teams:

  1. A handful of carefully chosen metrics should be preferred over a large volume of metrics. Ideally, each Agile team (and respective service) should be evaluated/tasked with improving 2-3 metrics (no more than 5). We have witnessed at least one company that proposed a total of 20 different metrics to measure an agile teams performance! Needless to say, being graded on that many metrics is disempowering at best, and likely to illicit either a panic attack or total apathy from your team. In contrast, having only a handful metrics to be graded against is empowering and helps to focus efforts.
  2. Easy to collect and or calculate. One startup suggested they would track “Engineering Hours Spent Bug-Fixing” as a way to determine code quality. The issue was quickly raised: Who would be doing this tracking? And how much time/effort did they estimate it would take?  It became obvious that tracking the exact amount of time spent would add a heavy productivity-tax to an already burdened engineering team.  While providing a very granular measure, the cost of collecting this information simply outweighed the benefits.  Ultimately we helped them decide that the “Number of Customer Service Tickets per Week” was the right metric. Sometimes a cruder measure is the right choice, especially if it is easier to collect and act upon.
  3. Directly Controllable by the Team. Choose metrics that your agile team has more or less direct control over. A metric they contribute towards indirectly is less empowering than something they know they own. For example, when measuring a search service the “Speed and Accuracy of Search” is preferable to “Overall Revenue” which the team only indirectly controls.
  4. Reflect the Quality of Service. Be sure to pick metrics that reflect the quality of that service. For instance, the number of abandoned shopping carts reflects the quality of a shopping cart service, whereas number of shopping cart views is an input metric but doesn’t necessarily reflect service quality.
  5. Difficult to Game. The innate human tendency to game any system should be held in check by selecting metrics that can’t easily be gamed. Simple velocity measures are easily (read: notoriously) gamed while the number of “Severity 1″ incidents your service invoked can’t be so easily massaged.
  6. Near Real Time Feedback. Metrics than can be collected and presented over short-time intervals are the most actionable. Information is more valuable when fresh — providing availability data weekly (or even daily) will foster better results than a year-end update.

Most importantly, well-chosen metrics tracked regularly should pervade all aspects and all levels of your business. If you want your business to become a lean, performance driven machine, you need to step on the scale every day. It can often be uncomfortable, but it’s necessary to get the returns of which you are capable.

Send to Kindle

Comments Off on Selecting Metrics for Your Agile Teams

5 Product Team Must Dos – the New (Old) Approach to Product

Want to create great products?  The path to success in this endeavor has more to do about how you think about value creation, think about your customers and organize your team than it does having brilliant ideas.  And here’s the kicker – while many of us think some of these concepts are brand new (including the founders of AKF who contributed to the primary research on the topic), the fact is that great companies have known these secrets for quite some time.  Here are 5 “Must Dos” for product teams to create great products:

1) Focus on customer value creation first!

In Peter Drucker’s “The Practice of Management” (1954) he wrote that “There is only one valid definition of a business purpose:  to create a customer.”  In later works he expanded on that notion by saying businesses must create AND keep customers and that profit was a necessity to stay in business, but not the sole purpose of a business.

Profit and shareholder value maximization are of course important to businesses.  Without profits, you can’t stay in business long.  Without creating shareholder value, you will be locked out of equity markets.  But by and large these are dependent variables outside of a firm’s control.  While we can control costs directly to effect profits, doing so may constrain our future growth.

If we instead focus on delighting the customer with the products we create, we can create internal and external enthusiasm for the product.  In doing so we grow revenues (part of profits) and excitement within the company.

 

2) Eliminate the “IT Mindset” and develop as a Product team

In the first edition of The Art of Scalability (2009), we cautioned teams away from the “IT Mindset”.  The IT Mindset is cost and efficiency focused versus the Product Mindset which is customer, market, product and revenue focused (in that order).  The IT Mindset envisions product development as a manufacturing plant, rather than the creative and innovative process it must be to be successful.  The IT Mindset has a purpose – to serve the needs of employee efficiencies – but should come with a “Do Not Use with Products” warning label.  This IT Mindset stifles innovation and kills product team morale.  Marty Cagan, one of the greatest product minds and consultants alive, and a longtime colleague and business partner, has more to say about this debilitating phenomenon here.

 

 3) Organize around the objective – not functions.

While performing academic research on why some teams in the same industry seem to have higher levels of innovation than others, we stumbled upon some interesting veins of tangential research.  All of them pointed to multi-disciplinary teams comprised of all the skills necessary to complete an objective and organizing around outcomes having higher levels of innovation and success than teams organized around functional boundaries (e.g. product management, software engineering, QA, operations, infrastructure, etc).  While we contributed to this research, we found out we weren’t the first to identify this phenomenon!  In fact, this Harvard Business Review article (1986) hints at the same philosophy.

 

4) Don’t listen to what customers WANT – watch them and identify what they NEED

We’ve all heard Jobs’ famous saying that customers don’t know what they want until you show them.  Developing a customer “want” is costly and can greatly miss the greater market opportunity.  As we point out in this post, product teams need to focus on the hypothesis for a market need, start small (MVP) and iterate their way to success to maximize the potential of a product to meet the true need.

 

5) Eliminate the concept of insular innovation

Forget the concept of a single great innovator running a company and generating great product idea after great product idea.  That concept is a myth perpetuated by marketing teams and egotistical executives.  The existing research on this topic is clear:  The teams with the highest levels of innovation source innovation from a diverse network of individuals inside and outside the company.  See slide 10 on network diversity in our scalable organizations presentation.  But don’t just take our word on it, Walter Isaacson comes to the same conclusion in his NY Times Bestseller “The Innovators”.  And yes, he debunks the notion that Jobs was the sole reason for Apple’s product success as well.

Send to Kindle

Comments Off on 5 Product Team Must Dos – the New (Old) Approach to Product

The Difference between “Want” and “Need”

We often hear Steve Jobs or Henry Ford quoted as reasons why companies should not listen to their customers.   People love to throw “Customers don’t know what they want until you show it to them” (Jobs) and “If I had asked people what they wanted, they would have said a faster horse” (Ford) as reasons why innovation should be a company run, insular, closed to the public process where a handful of smart employees define the future.

The problem with using these statements to defend insular, introverted innovation is two-fold.  First, such a position misunderstands both the context within which these statements were made and subsequently the point both innovators were attempting to make.  Second and most importantly, the position of supporting insular innovation simply isn’t supported and in fact is refuted by the extant research on the drivers of innovation.  The companies with the highest levels of innovation are and always have been outwardly focused and intent upon learning how customers interact with their products (see The Power of Customer Misbehavior and our research on innovation and scalable organizations).

Let’s tackle the misunderstanding of these statements first.  Both Jobs and Ford are identifying the difference between what customers want and what a given market needs.  Their point is that what a customer says they want is seldom what a market (a large group of customers) truly need – or at the very least that what customers want won’t be as good as identifying and meeting their true need. Specifying and fully developing a want is misguided by an untested hypotheses associating the to-be product with a desired outcome.  Because the specification isn’t guided and course-corrected by iterative testing against a market environment, the longer the program of development runs (and the larger the product), the more likely it is that the product will miss the maximum opportunity.  Waterfall development, while appropriate in some areas (such as negotiated contracts without room for testing against a real need), is all about developing a want codified within a product specification.

The alternative approach is to start with a necessary outcome (e.g. first digital encapsulated music player without removable mass storage media, or better transportation) and a hypothesis as to how to get there (hard drive for mass storage and software for transferal, 8 HP 2 speed engine and transmission with 2 or 4 seats).  In these cases, neither product took a long time to build (especially for “hardware”).  Instead, the companies looked to bring a product to market quickly and learn from it.  To show how quickly the teams were iterating and fixing the mistakes in their initial products, Apple released a new generation of their iPod or a new model every year for at least six straight years and corrected such initial deficiencies as not supporting Windows for the iTunes OS and not having a solution for digital music downloads (the iTunes store).  Ford produced 4 new car models (the Model AC, Model C, Model B and Model F) within the 4 years after initial Model A launch in 1903.  These vehicles addressed the engine being underpowered, overheating, weight limitations, etc.

The point here is that great product teams understand that the greatest value is derived from achieving the outcomes associated with a need, not the specifications of a want.  Needs are met by defining a measurable outcome, building a testable hypotheses (minimum viable product or MVP) as to what will partially fulfill that outcome and then iteratively and rapidly correcting the hypotheses (MVP) to achieve the desired results.

Send to Kindle

1 comment

CTO Bootcamp: March 10th & 11th in Brooklyn

 

CTOBootcamplogo

We are excited to announce AKF Partners very first CTO Bootcamp. This unique two day event is designed for current CTOs, VPs of Engineering, Chief Architects, and other technology executives that want to improve their management, leadership, and technology skills. Marty Abbott, Mike Fisher, and Mike Paylor from AKF Partners will share their combined decades of experience as CTOs and technology executives at both large organizations and start-ups.

The two-day bootcamp will cover the following topics:

The CTO Role: A discussion on the diversity of expectations and responsibilities from the 400 companies we have worked with at AKF Partners.

The Right People & Roles: Ensuring the right talent is placed in positions for success.

Management & Leadership: The skills of a transformational leader and highly effective manager.

Conflict & Innovation: A discussion of good and bad conflicts in organizations and how to increase innovation.

Multidisciplinary Agile Teams: Building innovative teams with diverse experience and skills.

Team Goals & KPIs: Setting goals, metrics, and KPIs for Agile teams to ensure success.

The Experiential Chasm: The widening gap between business leaders and technology leaders and how to close it.

Service Delivery Mindset: The most successful technology organizations are structured with a service oriented mindset and we will discuss how to transform your organization and mindset.

AKF Risk Model: Our viewpoint of risk and how to manage it successfully in your architecture, people, and processes.

Highly Scalable Architectures: An in-depth look at creating highly scalable and available architectures

  • AKF Scale Cube: Our approach to designing highly scalable architectures.
  • Creating Fault Isolation: The importance of isolation for availability and time to market.
  • Architecture Principles: An in-depth look at the top architecture principles and how to apply them.

Processes for a Learning Organization: The most effective processes to put in place to create a successful learning organization.

 

Our first bootcamp will be held on March 10th & 11th in New York. If you are interested in attending or sending a member of your organization please register.

Send to Kindle

Comments Off on CTO Bootcamp: March 10th & 11th in Brooklyn

Building Scalable Organizations

Embedded below is a presentation on building scalable organizations. The presentation walks through our model of innovation detailing how factors such as cognitive conflict, affective conflict, and a sense of empowerment impact a company’s ability to be innovative. The slides then depict how in most functional based organizations there is conflict when trying to deliver a service such as a SaaS product offering. The remainder of the presentation focuses on how to fix this with some real world examples of companies that have reorganized to focus on improving innovation.


Send to Kindle

Comments Off on Building Scalable Organizations