UX and Technical Debt

Marketo Retrospective Part 6
As part of a series, I am doing retrospective lessons from my 9 years at Marketo. Today, I focus on product development. Specifically about a philosophy I have around maintaining products after initial innovation.

When you have a startup, the first innovation is complete free from existing customer complaints. It is pure in that sense. It is only after you deliver that first product and customers are using it that you start to accumulate UX and technical debt.

Technical debt is a concept in programming that reflects the extra development work that arises when code that is easy to implement in the short run is used instead of applying the best overall solution.

From my 2011 blog post on technical debt.

Notice how the quality goes down exponentially with technical debt.
Notice how date driven releases contribute to technical debt.
Notice how new features are delayed because of tech debt

At Marketo, the technical debt load was very high. Part of this was cultural. We were strongly dissuaded from refactoring and improving code. For every one engineer like Crash who optimized code as he went, there were dozens who cut corners to make deadlines.

The real culprit here is date-driven development. This is when you focus on the deadline instead of the quality of the release. Usually, it is executives who pressure the team, not the team itself.

UX Lesson #9: People don’t remember the date you released your product. They remember the way it makes them feel. Focus on that.

Because refactoring was verboten, the focus became solely about new features. This created a very large codebase, but because of the debt, slowed overall development to a crawl. Ultimately, this became crippling. As a designer and product leader, I couldn’t stop the degradation of the experience without a massive payback of the debt. (In other words, rebuilding the application from the ground up)

No one likes paying technical debt, but it is crucial to the longevity of a product. Marketo made the mistake of driving development to a date, thereby causing cut-corners (technical debt) thereby slowing development down. It’s a vicious cycle and it sucks to be inside of it.

A series of acquisitions (social, mobile, RTP, SEO) made matters worse by introducing new codebases, new people and taking oxygen away from much needed existing products. There is this great post in the Marketo community from Gregoire Michel that basically lists a ton of UX/Technical debt. I wish that stuff could get the attention it deserves.

I take plenty of blame for the situation. Although I could say that it was other people who made the decisions, I was there and it happened on my watch. I did not persuade the powers that be to focus on usability, refactors, upgrades and feature completion. I rolled over and accepted that we were moving on. I tried to maintain balance, but in the process gave up my values about how products are built.

In the end, my lesson was mostly about what happens when you ignore technical debt and how lack of persuasion on my part led to this outcome. It is a poor leader who blames others for problems. Maybe with the new ownership Marketo will change their formula on paying debt. Time will tell.

Brand, Culture and Recruiting

Marketo Retrospective Part 5
As part of a series, I am doing retrospective lessons from my 9 years at Marketo. So far, the learnings have been in fits and spurts. Also, not much complaining so far.  Today, I’m thinking about how Brand Identity evolved at Marketo and specifically how it related to culture and recruiting.

DISCLAIMER: I have always been on the product team, so my perception is colored in that way. I know alot less about how sales people perceived the company.

2007, The Startup
Startups in the Bay Area usually have a particular vibe about them. If you have seen the show Silicon Valley, you know the type. Hyper-technical engineers paired up with over-the-top type-A executives/sales. The brand you have as a startup has to do with what technologies you are using and how well you explain your vision.

At Marketo in 2007-2008, we had a very, very low-key brand. We worked, we went home, we came back and worked some more. We didn’t get drinks together or have picnics with each other’s families. We just worked.  The first company bar-b-que was in the parking lot. It was pretty low-budget. The first holiday party was at the CEO’s house. I guess you would describe our brand as introverted. We weren’t the team to socialize all over the place. When people interviewed, we just tested their coding skills. We didn’t really spend time selling the vision.

2010, The Rocketship
By 2010, things were going REALLY well. We were selling product like crazy and growing people by leaps and bounds. However, we had never really worked out the values, vision, mission or brand. It was a lowest-common denominator approach. Nothing offensive, nothing lovable. We were just there.

This is the big tragedy for me. Marketo was a rocket ship at that time and we should have been the hottest place to work. We should have had our pick of the pre-IPO litter. However, the lack of focus on brand and culture led to a different outcome. Lots of B players were hired in those years. Even a bunch of C players got through.

No one likes to believe they are a C player (or worse), but truth is truth. People are different. This is why we interview and try to get good candidates. Brand and culture help you attract and close the best people. When you walk in the office, how does it look? Does it look like Apple or Google or more like Dunder Mifflin?  At Marketo, we looked alot more like Dunder Mifflin than we should have. We lost something by saving money on the environment. (Dunder Mifflin decor is less expensive)

Additionally, the lack of written values made interviewing and evaluation a crap shoot. By this, I mean that each interview team used different rubrics to decide who was a good fit and who wasn’t. It also made people who joined the company feel that there wasn’t a set of cultural norms to adopt, so they just kept their own culture. This led to a diffusion of culture and a lack of common vision.

2011-2012, Get ready for IPO
The brand become more professional and polished. Written values finally became a priority and were rolled out. They are Customer Passion, Results First, Speak the Truth, One Team, and Aspire to Be Great. For a year or two, they helped bind the company together. However, they started to wither after a while. Values are like plants. They need constant attention or they will start to die.

This is hard to say, because I mostly loved my time at Marketo. However, it wasn’t a perfect place. I think we allowed culture, values, brand and recruiting to all get second-class status. This led to the outcomes you would expect. Low quality of new hires, slow cultural absorption, more arguments about value decisions.

Value decisions are crucial to the health and wealth of a company. The values aren’t meant to be “mom and apple pie”. They aren’t meant to be good things like “be nice”. Rather they are tools to help you make a decision between choices that are equally good/bad. When faced with those decisions, you need to decide your character as a company and use that to make the decisions.

For example, there was a time when the competition (Eloqua) found a badly written response by a support rep in the community. If transparency was the corporate value, we would have fixed the problem and left it open to public view. However, that wasn’t the value of the company. Since that day, the community was closed to the public. (Customers only)

2013-2016, Post-IPO
Once you go IPO, it’s alot harder to hire the best-of-the-best. You have old technology and old offices. It’s hard to compete with Goliaths like Facebook and Uber. However, the public market demands a ton of growth or they punish your stock price. Here is where Brand could have helped a bit if we had a more lovable identity. Unfortunately, the brand was simple and professional, not lovable. The pressure to grow made hiring difficult and many people left the company with their IPO payday.

This led to a rapid infusion of B, C and some D players. This was a hard time for me personally. I started feeling more and more disconnected from the success of the company. One of my personal values is transparency, so I say all of this knowing it looks bad on me. I’d rather be honest with you though. I hope I am not hurting anyone’s feelings about all of this. (Even the D players)

2016, Vista Acquisition
This is a tricky time for Marketo. New owners, new executives, possibly new direction. Alot of people will likely churn. Brand, values and culture are more crucial than ever. I would suggest rolling them out again, fresh. Create a new beginning with a new mission. You have to start somewhere.

I don’t know what the future will hold for the company I poured my heart and soul into for 9 years. I truly wish them the best.

In hindsight, I think this is the area that could have improved the overall trajectory of the company the most. A company is, in the end, the people that work there. It can’t do anything without the people. Attracting and keeping A players is crucial. Think about your website: What does it look like to an A player? Don’t just sell to prospects, sell to new employees. Spend time on your environment and make it compelling. Keep your technology up to date. Get the values written down early and talk about them all the time.

That’s what I learned about Brand, Culture and Values at Marketo. I hope it was helpful for you to see that side of things. Again, no company is perfect and this post shouldn’t diminish my respect for the company and team that took it as far as it did.

UI Frameworks (2006-2016)

Marketo Retrospective Part 4
As part of a series, I am doing retrospective lessons from my 9 years at Marketo. I learned alot of things and this is my way of processing all of that experience into bite-sized nuggets of wisdom. Today, a little deep dive into how the client-side technology has evolved.

UI Frameworks
In 2006, I was introduced to jQuery and it changed my whole outlook on web development. When I joined Marketo at the end of that year, I was looking for something LIKE jQuery, but specifically designed for enterprise applications. What I found was YUI-Ext by Jack Slocom. At the time, Yahoo had something called YUI (Yahoo User Interface) which could be used to make applications. However, Jack (a programming genius) realized that there were no common components like drop down boxes, tables and trees. He built the components as an open source project called YUI-Ext (extensions).

Marketo’s first UI was built in YUI-Ext 0.33 Alpha. It was early days for sure and the code had plenty of problems. However, the time it would have taken to rebuild all of that functionality would have been enormous. As a designer, I was able to make a very rich interface without the huge investment of time. Here is a picture of one of the first screens of Marketo. (Interesting review of that 2007 app)

Notice how hokey it looks. Eloqua used to call us PlaySkool. Even our logo was not super deluxe.

However, building out tabs and trees and layout was SO easy compared to making everything by hand. In 2009-2009, we updated the UI and we took the opportunity to upgrade the UI Framework. Jack Slocum turned his YUI-Ext into a company called ExtJS and dropped the dependency on Yahoo. We skipped version 1.0 and upgraded immediately to 2.0. It was a 9 month project, but when it was done, the UI was faster and sleeker.

We used to name all of our releases after elements in the periodic table like Hydrogen and Helium. This was the Carbon user interface. It was a great year for Marketo. The UI was new and easy to work with. We started to grow rapidly and make lots of sales. The UI framework, again, was a key ingredient in build a next generation interface without spending insane time on it.

Eventually ExtJS renamed themselves to be Sencha and the product was called ExtJS. The Marketo interface got more and more complicated. Elsewhere in the world, new frameworks were being introduced like Angular. Sencha has a few releases that were not excellent and were not easy to upgrade. 3.0, 4.0 and 5.0 were progressively harder and harder to manage. Eventually, the engineering team gave up and we were stuck in an old UI framework that we couldn’t upgrade.

This huge benefit had turned (after 7 years) into a huge liability. Creating new features became very difficult. The larger team struggled to learn the system that had grown to be gigantic. Think of all the things Marketo does. There is programming for all of it. It’s alot.

I wanted to upgrade the system, plus the UI was starting to look old. The cool skeuomorphism of the past had been replaced with the flat Apple look of the present. Rather than upgrade the framework, we just upgraded the CSS styling. In the spirit of the elements, I called that the Cobalt user interface.

Notice the flat look, no gradients, no rounded corners. I didn’t love this look, but I did my best with it at the time. The worst part was not upgrading the framework. I set myself on a journey to try and upgrade the framework. The reason was that recruiting had become difficult. No one worth their salt in Silicon Valley wanted to work on 5 year old technology. Also, the slowness of the interaction along with the slow pace of development made creating new features intolerable. The roadmap slowed to a crawl and routinely UX goodness was cut from scope.

Finally, the decision to bite the bullet and change the whole UI framework was made. This is a huge decision for any company to make. Currently, in 2016, the framework of choice is React and Redux. This framework is the coolest shit of the year. It makes development a breeze. At Marketo, changing the UI also required changing all of the internal APIs away from PHP towards something more powerful like Java. This is a particularly huge process, but it is unavoidable if you want to move forward.

The newest UI was named after the element Mercury. It was my last project and I left as it was beginning engineering. Since I left, the look has apparently changed significantly. I don’t know what it will look like. I have have my old designs of it from last year, but it will be surprise to me when I see it. My design used some patterns pioneered at Slack and also used at Salesforce Lightning.

Looking into my crystal ball…React and Redux will be replaced with other technologies and become old and crusty. It’s a never-ending cycle. There is infinite desire for speed and flexibility.

Well, that was a longer blog post than I anticipated. If you made it this far, you get a cookie. (Go get yourself a cookie and say “this is for the blog post”.) I hope you liked it. (The post….and the cookie).

UPDATE
I forgot to mention, with React and Redux, you can use this awesome component library that works like Google Material design.

Remote Offices

Marketo Retrospective Part 3
As part of a series, I am doing retrospective lessons from my 9 years at Marketo. I learned alot of things and this is my way of processing all of that experience into bite-sized nuggets of wisdom. Today, here is what I learned about remote offices.

Sales Offices
Marketo had many sales offices around the country and even around the world. After a certain amount of people, it totally makes sense to distribute. It’s much better to close a deal in Australia if you actually live down under. Having centralized sales may be useful to some, but I clearly saw the benefit. The downside is that it is incredibly hard to teach the remote offices about new features and make sure they are demonstrating the product effectively.

Services and Support Offices
This is actually one of the best uses of a remote office. These are generally lower paid employees and going to a less expensive location saves money and gives a better quality of life to the employees. It’s easier to learn new features because you are living in it all day. Additionally, you can provide more hours of support if you have offices around the different time zones. Ireland and Portland were especially effective support locations.

I wish I had talked more with the people in Ireland. I think they wanted to talk with me more, but the time zone difference made it really hard. I would call the office a success, but it also lacked many benefits you get from working closer.

Engineering
This is the one that most Silicon Valley companies struggle with. If you have a blackbox situation then India or Eastern Europe is an option. You need a rock-solid specification or you will end up with something weird.

Blackbox engineering situations is when you need something built that does not have any knowledge of the rest of the system. Also, the rest of the system doesn’t need to know how the blackbox works. It just does a simple job. Thus, it is easier to outsource because the communication requirements are lower.

I have worked with great engineers and poor ones in all parts of the world. I feel like there is a formula that has something to do with:

  • Q = Quality of engineer
  • D = Number of time zones distant
  • C = Complexity/Length of project

The point is that remote workers create challenges that onsite workers do not. You can still be successful with a remote worker. I worked on a project with a superstar from Amsterdam named Ian. If he was a lesser engineer, then the project would have taken twice as long. I also worked on the Marketo community version 3 (its currently version 4) with a team in India. That one did not go as well, because the talent wasn’t as good AND the number of time zones distant was too many.

There was also a Portland team of engineers that were actually a delight to work with. This had alot to do with the head of that office (Shaun K) who was such a great leader and communicator that it just made things go better. The fact that they were in the same time zone helped tremendously. They (or I) could fly and visit often.

In Silicon Valley, engineers are highly recruited. Google, Apple, Facebook, Box, Uber and others all try to recruit a limit set of engineers. It’s hard to be a startup and get the best. However, in Portland or Seattle you can be a bigger fish in the pond. Creating a remote engineering site makes sense for economic reasons, but you need to create extra communication channels for PMs and Designers to talk. Specifically, I found video conferencing to be a great bridge between different locations.

The pool of talent in the Bay Area for a mid-level tech company that has already gone public is fairly small. This led to an erosion of talent in the San Mateo office. Realistically, unless you are prepared to compete with the perks Google doles out, a remote office may be a better option.

In the end, I think remote offices are a reality if you want to scale. You just can’t have everyone in the same room forever. The lesson I learned was to over-invest in communication vehicles like video conferencing, tele-presence and Slack. Also fly people in both directions frequently. Also, I would try as long as you can to keep the engineering teams in the same time zone.

When I started this post, I thought I had alot of good learnings, but here I am at the end, and I think I have very few concrete suggestions. Something for me to think about, I guess.

UX Follow-Through

Marketo Retrospective Part 2
As part of a series, I am doing retrospective lessons from my 9 years at Marketo. The time was filled with good and bad and everything in between. Looking back is the best way to learn and do better in the future. This time, I am looking at UX follow-through.

UX Follow-Through
In the beginning, I designed the Marketo Smart List and said, “It is good.” Well, that’s not true. It actually sucked at first. People don’t remember how buggy it was in 2007/2008. Also, the interface lacked much of the elegance it has today. The reality is that the current Smart List is version 6. Paul Abrams and I worked hard to polish it and rework it until it was just right. We had good UX follow-through. We didn’t just stick with version 1 and the effort paid off. People today love the Smart List.

Unfortunately, most of the other features of Marketo did not get the same benefit.  The story explaining why that was the case is basically the same for each feature. Here is one example: Workspaces.

Marketo Workspaces were designed while I was gone in 2010, but I inherited it once I got back. Once you inherit something, you need to own it as much as if you built it yourself. In this case, the lack of a central “HQ Workspace” made it nearly impossible to manage shared assets amongst the different workspace groups. It was pretty obvious at the time that this was a miss and needed refinement and features. However, what happened was the the “powers that be” decided NOT to follow-through with the feature. They cut it short and released the (unfinished) feature, never to be worked on again. My efforts to keep going on the feature were fruitless. I was disappointed and not proud of the feature, but I couldn’t do anything to prioritize fixing it.

One might say that I should have designed the feature perfectly the first time, but this just isn’t the way the world works. No one (to my knowledge) designs things perfectly the first time. Great products require some revolution AND some evolution. This is a key lesson learned and something I would do differently the next time around.

Other features that had UX or features stripped out and were hardly improved after the initial release. Marketo features without the UX follow-through include:

  • Revenue Modeler
  • Operational Reports
  • Social Widgets
  • Programs
  • Calendar
  • RCE
  • All the Analyzers
  • Import Library

This isn’t to say the features are worthless, far from it. Rather, this is about following through on a half-created great idea. Those features were great, but needed more effort. They needed time to evolve.

One technique is to ban all time-boxing in the product development. Release the feature when its finished, not when the due date is up. It is true that engineers and designers might fiddle with things for a while, but maybe they are doing important fiddling. Let the designers and engineers figure out when they are done. Focusing too hard on a date will force everyone into thinking about cutting corners rather than delivering a lovable product.

The good news is that so few products have follow-through. It means you can be really great in comparison. Just remember, people don’t care how hard it is for you or when you launched it. They care how it makes them feel. Focus on that and you have a much better chance to succeed.

The Power of a Single Word

I am a firm believer in retrospectives. How can you expect to improve without looking back at what you did? I am going to do a series of lessons learned from my 9 years at Marketo. Doing one giant post will be too long, so I’m breaking it up. This is Lesson 1.

The Power of a Single Word
Early research (2007) led me to understand how Salesforce.com labels different core entities. The one that was most important was the word “lead”. In speaking with SMB companies, the word lead meant “a person”. When they went to a conference, they collected new names, each one was a single lead that represented a single human being.

Also, Salesforce had a word called a “contact”. A contact was also interpreted as a single human being. How could this be? There were two objects, each one representing a single person. I thought this must be a stupid mistake by Salesforce. So what I did was design the system so that leads and contacts were the same thing, a “person”.

This got baked into the very essence of Smart Lists in the Marketo schema. It was crucial to how the whole system worked. Duplicates were thought to be a problem that needed fixing. If you had a lead and a contact of the same email, that clearly was a duplicate.

Unfortunately, the enterprise market did not interpret the word Lead in the same way the SMB did. They interpreted the word the way a homicide detective would use it. “I am following up on a few leads.” In this usage, a lead is a clue. Several leads may lead to the same contact. So in other words, if someone downloaded 3 white-papers, there should be 1 contact and 3 leads. The enterprise would then merge the leads into the contact when the time was right.

I had a long-standing project that never came to life called Purposeful Duplicates. The whole point of that was to allow a single record to the parent “person” and then you could have many leads or even contacts underneath that represented manifestations of the contact. In other words, a “proper lead as clue” schema.

Because of the focus on people, my design of Marketo did not really support Accounts in an especially useful way. This led to many limitations with the product.

The whole problem started with the interpretation of a single word, Lead. If they had called it an “activity” or an “interaction”, I would have designed the system very differently and probably would have made the company more money. That is the power of a single word. It may have cost the company hundreds of millions of dollars in valuation.

English is a blunt language. It’s so blunt, in fact, that it had to borrow the French word for nuance.

My Design Process

I’ll try my best to be concise.

Step 1. Receive commandment from God
Or your CEO or your PM or boss, whatever. They will say something like, “We need _____” Fill in the blank with any two word feature. (Example: Dynamic Content, Enhanced Security, Cool Dashboards.

Step 2. Talk to users
Is this obvious? I say users instead of stakeholders because I actually want to understand the lives of the people who will actually use the system. Who are they? What do they do for a living? Look for painful parts of their job.

Step 3. Design a mid-fidelity storyboard
Nothing that takes too long, but high enough fidelity to give the idea. I find black and white wireframes or sketches are too simple to get people to understand and give meaningful reactions to.

Step 4. Iterate on Step 3
Show the storyboard, modify the storyboard, show, modify, show modify. Keep your old work, they are fun to look at later. This iteration takes as long as it takes to get people excited about the results. Don’t stop iterating too soon. It should get better and better. Sometimes you have to erase everything and start over.

Step 5. Build it
For realsies, no prototype, no usability testing, no focus groups. Just build the fucking thing. What are you waiting for, an engraved invitation?

Step 6. Train people how to use it.
This is crucial. You have to train people yourself, in person. See their faces. Every time you see a grimace or a confused look you need to take note. These may be documentation issues, metaphors or worst case a complete fuckup in step 3-4. Most of the time they are minor usability bugs. Get them fixed. Learn the language of engineering and get these bugs prioritized. If possible, personally make the documentation outline. No one can train people as well as the designer who understood how and why it was built.

Step 7. Write down all the shit that got cut from the project.
This is an awful step, but you have to do it. That animation you liked, that usability feature you wanted, that feature that made it all work better together. Write them all down in an epic. You will have to bring that back up one day when you want to improve the feature.

That’s it. It’s worked well for me for over 20 years. The key part of the design is Steps 3-4, that’s where the magic happens. Get good at step 3-4 and you will have a good career.