Boom! Avoiding Landmines: Product, Engineering, Strategy and Transformation

I consulted for roughly fifteen years in Engineering, Product Management, Transformation and Strategy across multiple industries and segments (Banking, Fitness, Energy, Telecommunications, Health, Insurance) (Subscription Services, Marketing, Growth, CRM, E-Commerce and Tech). In this article I am going to discuss the things that I saw that were most successful, and the things I saw that caused product and business failure, high churn, low moral and low output.

Technical Debt:

There are places like Bangor Savings Bank where their server room was a dream all the wires were managed, things were labeled and organized and they invested in their foundations. There were places (not to be named) where when they had to move their servers, and in order to move them they had to put it on a cart and plug it in every so many feet to move it as it was the original server built in the basement of the startup 20 years ago and never updated! (they were worried that it would not stay up if it went down). Notably at several places (mega companies) where the freezing cold server building had wires that looked like a massive mess of spaghetti. I have seen places with a file thirteen for all tech debt ideas in a backlog that never get done only to get looked at when all operations stops or the entire e-commerce website goes down. Too often looking at backlogs I see per sprint (if agile, next topic) with less than 5% allocated to technical debt, this is a big no no. If you fail to address your tech debt now you will have to address it sometime later and at a greater cost. I strongly suggest about 20% of your allocation to go to technical debt and foundational innovation (cloud/ technical modernization).

Agile-Ish:

Agile "You keep using that word.?I do not think it means what you think it means". This I saw a lot of, especially in Banking, Energy and Insurance. One suggestion if you are moving to Agile (and you should for so many reasons) invest in a quality Agile Transformation Coach. Way too many times people associate agile practices with no process, no framework, or just to be synonymous with "quick". There are many agile frameworks out there and to outline each and the pro's and con's would be a total other article (and most likely many articles). Each framework does have consistent practices that allow teams to move quickly on experiments and products, but are still frameworks with best practices, processes, and methods to deliver excellence. If you are going agile you will also absolutely without a doubt need buy in from both technical and strategic leadership both sides need to agree with the new framework and support the change management process across your organization. Do not do Water-Agile, Do not do Water-Agile, Do not do Water-agile. Commit to either Waterfall or Agile, water-agile will lead to disaster as the methodology, timelines, allocations and budget are as murky as swamp water.

Change Management and Transformation:

For large scale transformations (such as going to Agile) enlist the help of an outside change management firm it is important to have a 3rd party that is objective with fresh eyes to help spot opportunities if and when doing large scale organizational changes. Also, change always comes from the top, find executive (C level) buy in for major transformation. Make changes iterative, clear, and with enough runway to train your team/s via multiple learning styles (Video, articles, classes, live, Q&A to name a few). Make a clearly defined plan (project management skills) and understand your "personas" (your team) and how you want to target those "personas" to become champions of your change.

User Experience/Design Inclusivity:

A/B testing, Heatmaps, user interviews, app and web triggers and tagging and other things that are implemented in your first steps in ideating a product are incredibly vital to the success of your products. There is a balance between research and being disabled by data, between assumptions and checking those assumptions. Companies loose millions and in some cases billions by not checking their assumptions first (especially in waterfall development) yet moving quickly to actualize value.

Design inclusivity is important this is where your UX/UI people are super vital as they can spot things like is this color pallet going to work with color blindness. Did we include pronouns so that when a customer service agent calls that customer as they wish to be (common etiquette) misgendering a person is both embarrassing and a bad customer experience. A good designer will spot out things like font size or type going to cause vision based issues. It also helps you avoid compliance issues around things like can a visually impaired person who has reading software understand the images on your page, and is your product accessible. Do your customers feel welcome?

These areas around users and design inclusivity are often missed and often the cause of a lot of gnashing of teeth later. I have had clients spend large chunks of backlog to having to fix a ADA compliance issue after being threatened with a lawsuit or compliant. Address your design proactively, it will save you in the long run.

Strategy and Prioritization

Having a strategy around value dimensions in product prioritizations (business and technical) to give clear priorities once a roadmap is built that way its not only the loudest voice in the room heard but the most value based work, in the shortest amount of time. This is as simple as looking at business goals: growth and aquisition, churn reduction, funnel movement, time spent on site, time cart to checkout, NPS score improvement, risk reduction (the list goes on). As well as looking at technical goals: latency, accuracy, redundancy, risk, tech debt. Technical and Business value dimensions is a way of looking at product prioritization objectively especially when there are budget constraints and too many asks.

Culture & Moral:

Layers, layers, layers is the only phrase you want to hear during the winter. Too much hierarchy costs a business in many leaders and very few do-ers. Too much hierarchy also slows the business down and often crushes true innovation as product ideas rarely make it to the top. Structure of course is always needed but adopting a structured yet egalitarian model will allow you to consistently innovate and do what is best for your customers and for your business quickly. I have seen products (especially in regulated industries, and it does get tricky in this regards) take up to 15 different tiers of leadership to sign off, and up 5 demos across massive 50+ person per team groups for a single feature. In the time it took to do the demos (as engineering has to be present) one additional feature could have been completed and released. Most engineering teams are global meaning multiple time zones have to be coordinated, thus more is less time to work and get things out the door. Find the key people who need to make the decisions, they need to be included this should be 1-10 people max in one maybe 2 demos if its high stakes.

50+ and thriving, not really, at least in this case. Overworked, lack of vision and priorities- If the majority of your team is working over 45 hours you are either understaffed, have a lack of vision (and priorities) or an actual emergency on your hands (outage/cutover). I have come in as a consultant at clients where engineering moral was bad enough that the "I'm fine" burning house meme became a zoom background on a rotating basis (during the pandemic, during scrum calls). Lack of vision, context switching mid sprint and intense prolonged periods of 50/hr work weeks will burn out the best employees. Learn to prioritize your employees and roadmaps they are the backbone of your success. These things have real costs associated with them. There are ton's of YouTube videos on the cost of burnout as well as the cost of context switching.

Culture matters, how you treat people matters, this one should be a no brainer. I see often times engineering treated as a vendor (including internal teams) I see product as the scapegoat of sales, and sales (or marketing) the scapegoat of executive leadership. The more leadership (C-level leadership) sets the tone of we are all one team, we all succeed as one and how do we support each other (and leave "it's not my job" at the door) the more successful we are. All areas of the business when harmonized, communicating and not pitched against each other like a bad episode of game of thrones leads to success and good energy.

Ending thoughts:

The above article captures only a small snippet of things you can do to see success in your business and is 100% not inclusive of every aspect. These are though in hindsight 2020 (okay not even sure if hindsight 2020 is okay to say anymore) the areas I've seen over the years are some of the biggest gaps companies make. My hope if you are reading this to avoid these landmines in your organization and business as you consider that the problems each industry and organizational area (Product, Marketing, UX, Finance and Engineering) are very common, just different jargon, users, products, and governance (if regulated). I've worked at companies that were startups, and companies that had thousands of employees global offices and global regulations. Let me know with a like if you found this article helpful and comment.

Next articles: Telling stories with data, and Building UX for Diversity, Equity and Inclusion.