This is me venting about the the top 5 fake candidate moments. I hate this new world.

I swear to you, this guy didn’t pay for the upgraded version of Magicam, which I had just learned about on this call (PLG FTW) when I googled the watermark.

According to his resume, he was very senior, working at top tier companies — a first red flag — in silicon valley for the last 16 years. After so long working in the USA, I would expect to be able to have a free flowing conversation. That did not happen, he said on the call he was from Spain, but he clearly was not. He was using someone’s LinkedIn on his resume, and he was face swapping with photos from that LinkedIn. Some of the facial features were coming through via the face swap, but there was something dead about the eyes so I might have figured this out without the watermark.

If the real Brian is out there, this guy stole your nose.

These are people who have somehow taken over a formerly real, but since abandoned LinkedIn profile. There’s been multiple data breaches on the platform with millions of credentials released so I don’t imagine this would be that hard. Lot’s of people give up on platforms like this and leave their accounts active and walk away, and they’re ripe for the taking.

In many cases, the most recent experience is a stealth start-up, sometimes it’s stealth for 5 years too long — another red flag.

Another super common tactic are people that replicate linkedin.com/in/firstnamelastname with the hyphenated version linkedin.com/in/firstname-lastname. In many cases the experience and education is the same.

A cursory google of your candidate will yield what seems like valid results, but upon further inspection, it starts to look quite suspicious.

If the linkedin for your candidate is /john-doe, then test to see what /johndoe is and whether it’s a copy.

The job hunt can be very dynamic. There’s lots to keep track of, and responsiveness as a candidate is an important quality. I can appreciate, especially for engineers, the desire to automate large parts of this process. I’d recommend avoiding email automation on reply. Much like everything, there’s edge cases that if not accounted for can make that process fall apart. I guess, for one, show up for your interviews. If you don’t, ensure your autoreply bot has accounted for that potential scenario. Maybe avoid automated communications to begin with.

There used to be a time where the most lazy of applicants would send cover letters that looked like

Now I tend to get cover letters that include continuation prompts from chatgpt where the user just copied the entire response, including any additional clarifying questions.

I expect most people to use some sort of AI to help them write because they think they need to personalize their application but they don’t actually want read into what the company is about or any details about the role. If you’re doing this, just proof read the darn response before you send it.

We're looking for candidates within certain time zones, with a number of regions that are off limits. This isn't stopping people though. I would guess that nearly half of the calls I got on, people weren't geographically seated where they said they were. 

If you don't have IP or geo logs on them, local sports pop-quizzes work like a charm. If you went to FSU, you would know the Gators. If your city won the Superbowl, you'd know some names of star athletes that I throw at you. If you hear rapid googling or eyes darting to another screen, they're likely full of shit.

We’re hiring full stack engineers, or if you’re mostly backend that works too. We’re python, django, react, react native, expo, leaning heavily into AI. We're a series A backed fully remote team of 12 with a D2C app in the digital vault space. Upload your CV here, and if you seem like a good fit I’ll respond with more details.

It didn’t matter. Our win rate didn’t change.

Here’s a few things I’ve learned about RFPs over the years.

A common sales process in B2B enterprise looks like this:

I know this happens because I’ve been a ghost writer on an RFP that a prospect would be distributing to a dozen other vendors.

It’s also very easy to identify proprietary terminology that competitors use.

Here’s a couple examples.

What is a real-time configurable smart widget? What is job stacking? I have no idea. If it sounds like marketing speak, it’s probably coming direct from a competitors website or one-pager. Do some digging.

So if I am lucky enough to be ghost writing my prospect’s RFP, at least we’re going to win right? Not quite.

Something that happens inside your prospect’s org when they begin defining requirements, is that your champion takes the requirements that you worked on together and circulates those to dozens of other stakeholders in their company.

In a bizarre game of one-upmanship, it’s now a competition to see who can add the most requirements. Who can make the bidders lives the most hellish of hellscapes? You can often clearly see the shift in language and terminology used in RFP requirements where a different stakeholder pasted their needs into the doc.

It's common that, after this requirements dump, no single person reviews, consolidates and does a reality-check on the needs outlined.

As a vendor, your job is to determine whether you want this. It’s costly to bid and often more costly to win.

Spending absurd amounts of time across your org doing RFP submissions is rarely quantified from an ROI stand-point. If you’re in a type of business where RFP bids are involved from time to time, do your best to understand if it’s worth it. A typical RFP bid could take many hundreds of hours, from start to finish, especially if you progress past initial phases. Not only does this have easily quantifiable real costs, but the process also has runaway opportunity costs involving the product team, engineering, sales, legal and marketing.

Also keep in mind that you’re probably not scaled to address the implementation needs and will need to ramp up hiring immediately if you win. It’s also highly likely that your bid price is 50% of your list price.

In the case of RFPs, think of it like you’re buying a logo. You want this nice logo on your website, in case studies, in press releases and in CEO powerpoint decks. What is this logo worth to you?

Often you assume that by saying yes you'll be penalized down the road when you get found out. Did we lie? No, we selectively understood the requirements in a way that we could meet it. The thing is, nobody really needs 80% of the shit that's in an RFP, and they will never hold you to that. The implementation will take 3x longer than promised and your champions will no longer be with the company by the time you’re rolled-out anyway.

By winning large RFP contracts, you will get buried, but not by the requirements you said Yes to. You’ll get buried trying to implement and retain this customer. Every week will be a new urgent requirement that was never covered in the RFP. We need to integrate with Qlik!! We need a data warehouse! We need to restrict access to the app to certain IP ranges!

Proceed with caution.

Our team was tight, fully remote for a decade, and Pete was part of it for 7 years. In the software engineering world, 7 years at the same job is a lifetime. The thing was, we’d never met Pete. Only a few of us had actually met in person. He was several time-zones away and I don’t think I could pick him out of a lineup. When we connected for meetings, we didn’t use cameras so I’d only seen a few images of Pete in family photos that we’d shared between us. I was the person who hired him and even during the interview process we didn’t use cameras. Nonetheless, I felt like we were in sync, we were friends, and he was a crucial part of the team. We talked frequently about music, family, video games and his love of Disney. I learned about his local politics and his views on the world. I loved Pete.

We fucked up. We had no connection to the people in Pete’s life, like his wife and kids. Pete was a full time contractor. This was a typical arrangement for over half of our team. We were scattered all over the world and we got started with a global team in the easiest way, which was hiring engineers as contractors. Pete had no HR, no health benefits, and no employee record with alternate or emergency contacts. We had 600 people in the company, but he was only known to about 10. And from the perspective of his family, they only knew the name of the company he was contracted with and my first name, but nothing else.

When he passed away, his wife had no way to contact me or anyone on his team. When I arrived in the morning, I got a message from our customer support team lead. Pete’s wife had used the technical support chat to get a message to me. She was put in a queue with every other customer user who couldn’t login or forgotten how to access the mobile app. I was gutted by the eventual news and by the fact that Pete’s passing had become a support ticket. This made it so much more devastating.

If you work with full time remote employees or contractors, please put channels in place to communicate with family or alternate contacts. Make sure emergency contact info is shared on both sides.

The team was lost. Because he was a full time contractor and not an employee, there was no HR intervention to help. I honestly don’t know if HR does help in these situations, but I like to think they could schedule grief counseling or something. We initially didn’t know what to do, or how to mourn.

We started by letting the organization know that we were all struggling. We ran this all the way up to the CEO. Because of his remote contractor arrangement, nobody outside of our team would have known that anything happened. We’d be postponing releases, this sprint was fucked, the next one too and maybe more to come. We needed time to pull it together. We’d lost a real one. 

Messaging the broader company and other teams was key. Some people are pros at what to do in these situations and they can operate with a clear head. Before long we had UberEats delivering to Pete’s family on the other side of the world, kind memories and words circulating and we had donations going to Pete’s local mental health organization. Our team, in our current state, could not have pulled this together without the help of the broader company.

As a squad, we decided the best memorial was an Easter Egg in the app. Pete was all over this app. He was prolific. This team and teams to come would be maintaining his code for years.

Pete deserved his own route. We created /Pete and put a page there memorializing him in code. This wasn’t a traditional hard-to-find easter egg. It was top level. Just add /Pete to your address bar and you’re there. This seemed right. 

It’s easy to think that we could have prevented Pete’s death. Our team spent the most time with him on a daily basis. I remember doing a ‘share photos of your workspace’ with the team, and being shocked by Pete’s workspace. 3 keyboards stacked on top of each other, heaps of peripherals, old broken monitors, headphones, piles of trash, a total mess. After seeing this, I began to learn a little bit about the scope of Pete’s challenges.

Pete would ask to work more hours. He claimed he could use the money. He was a contractor remember, so more hours means more money, and I could reconcile this without thinking twice. Who doesn’t want more money? After he passed I learned that work was a distraction for him. It gave him something to obsess over and he could think less about the mental and emotional struggles that were plaguing him. His wife sent photos of a bunch of handwritten notes of JavaScript that were lying around his room. She had went looking for a note, a clue as to why. She said ‘maybe you can make sense of these.’ I couldn’t, but I knew people who could. It was an iframe dynamic height function. It was work.

Could I have pushed harder to make him an employee? Prior to getting acquired, the process was underway to sponsor Pete to become an employee. After the acquisition, this sort of stalled and wasn’t something our new owners had interest in at the time. I could have pushed harder. I don’t know if it would have helped, but the thought still lingers that some things may have helped, such as having HR oversight, health benefits, and mental health affordances.

Pete was Scottish and he had his own slang which I loved and miss dearly. When he found a bug, he’d say ‘Caught a wobbler!’ I loved this. Pay attention to your team. Build closeness. Get to know about everyone’s family and private life. Take mental health seriously and talk openly about it. It may seem like prying, but you might catch a wobbler with a team member that you can address early.

RIP Pete.

@sofuckingagile

This was a rare learning opportunity and further deepens my respect for the craft of sales. I saw all sorts of successful and unsuccessful calls. I’ve documented some of my findings for no reason other than to share and offer some opinions.

It's been studied and reported that gender diversity leads to improved business outcomes, yet sales teams remain largely a boys club. Stats say that nearly 1/3 of B2B sales reps are women, but I didn’t see it. On the calls I studied, around 10% of the reps I saw were female. On the buyers side it was much more balanced, but on the sales side it was largely men. My skewed insight is likely tech industry specific, however the stats indicate that female representation is apparently trending up. 

In most sales orgs, calls are being recorded by Zoom, Gong or Chorus. To my surprise these calls are littered with countless discussions of health. Who has Covid? Who had covid? Who is vaccinated? Who is pregnant? Who is having surgery? It was all there. Most of this discussion happens during the small talk portion of calls, or even when the internal team is on the call before the prospect arrives. I have no real recommendation here, but it’s important to take extra care with this call info. When I think about my health information being compromised, typically I’m thinking about EHR systems, but it’s safe to say your exposure is much broader if you include call recorders.

Most sales reps talk too much. This is especially apparent when you have the text transcription in front of you and with a glance you can tell this call isn’t going to go very well. When you see walls of text in the transcript, that means sales monologues. This is especially common when someone is demoing software to a prospect…rambling about feature after feature and never checking in and never really digging into the prospects pain and letting them share. 

Maybe this is my outsider, non-sales opinion, but not enough people are asking for the deals when the opportunity is right there. I know there’s dozens of sales frameworks and reps are instructed to follow the process, but holy shit you have to recognize when someone is ready to buy. There were times I’m listening to the call and yelling into the void ‘close the deal!’ but instead the rep books the next in a series of zoom meetings and the sales cycle stretches on. I think this is directly related to most reps not knowing when to shut the fuck up and listen.

The winning sales teams were paying attention to signals and willing to throw the plan out the window and dive into the logistics of buying. One team would regularly guide the willing prospect to the signup and purchase form to ensure the sale happened on that call. I never saw anything shady or misleading, it was just a sales rep that saw an opportunity to cut a month off the sales cycle. 

In this project, I often would follow the sales journey all the way through the handoff to customer success, onboarding and into quarterly business reviews. During the sales phase, it’s exciting, and aspirational. People buy into this better life. They buy the dream. But then reality hits and you realize change is hard. You can achieve that future state but only with the most diligent of management and some serious work.

Sales teams that were most successful managed these expectations early on and were clear about phased adoption and milestones for success. They were constantly reselling post-sale and guiding the user to value driving activities. The best of the best had in-product dashboards that showed that value and ROI metrics so everyone had visibility. For example, if you were selling a prospecting tool that helped RevOps teams, that tool should have a dashboard showing leads created all the way down to ARR impacted.

Speaking of reselling, each year 20% of your customer champions will change their jobs. This ramped up since Covid and 2020 saw 37% leave their job. This means that your champion that helped usher your product into their company will have a good chance of moving on. When a champion leaves this puts ARR at risk. Unless you’re being proactive and inserting yourself into the conversation with the replacement, it’s likely that come renewal time that your product will be at a high risk of churn. 

The more successful teams were using tooling that let them monitor job changes on LinkedIn and to allow them to be proactive in finding their new champion, and reselling their old champion at their new job.

Many teams are enabled for discounting. Being involved as a product leader in B2B SaaS deals for years, I’ve known the extent to which my sales counterparts can discount. Depending on the deal size, the discounts I saw ranged from 10% - 60%. Sometimes the discount was positioned as ‘free months’ and in some cases it was a ‘lifetime’ deal. As a prospect you didn’t even need to put up much of a fight, you just had to exhale loudly at the right time and suddenly discounts are coming your way. It’s hyper competitive out there, especially at end of quarter.

One of they keys for a sales process to be successful is reliable data in Salesforce. It’s always amazing to me when a universally loathed tool like salesforce continues to dominate. 90% of the calls I studied came from teams using Salesforce. 

A sales journey can have a prospect talking to 3-4 job titles within your org from BDRs, to SDRs, to AEs and more. The handoff of that prospect between sales roles is normally completely powered by data in Salesforce. If this data is lacking, your prospect is having to repeat a lot of their background over and over putting the sale a risk.

When I saw teams with great Salesforce hygiene they were almost always NOT actually using the Salesforce UI. They leveraged tools like Scratchpad or Dooly to make the data entry part less cumbersome. These tools add a user friendly layer on top of Salesforce. This paid off with shorter and more meaningful calls and in the end higher close rates and shorter sales cycles.

Product led growth is all the rage. Everyone wants to be the next Dropbox. When your free tier users work at large enterprises, sales wants to get involved to turn that handful of free users into a large enterprise account deal.

Sales teams really sucked at this, and I saw them waste their shot over and over. If you have free users at a marquee logo, do your homework before getting them on a call. So many times I saw reps just see ‘bigcorp.com’ in a free tier email address, and somehow managed to get them on the phone and had no plan after that.

You should have all the product analytics you need to determine where they find value — they’re your users after all. Be prepared with a slide deck outlining the success you’re seeing in their usage analytics. Get them on record articulating how this has led to success at work and how they’ve impacted their OKRs by using your software. Find out how purchases are made and be prepared to put in the work to create the sales presentation using their own data and testimonials that they might use internally to pitch stakeholders. Ask if you can be involved in those meetings and be prepared with discount incentives. Don’t waste your shot.

Some good news for product and engineering teams. Very rarely did I see sales teams misrepresent their products. They were not making promises about future development or direction. Sometimes things were left unsaid, in order to not open a can of worms, but I see that as fair game. The only people who were in a gray area around promising product functionality that didn’t exist were founders.

The other big finding for teams building products is that these calls are FULL of insights for product direction. There’s a good chance almost none of these insights will reach product and engineering without intervention and building a purposeful communication process. I’d recommend getting access to these recordings and making reviews part of a routine.

@sofuckingagile

As my career evolved, PowerPoint became a niche way of communicating, reserved for those with a knack for presentations. It eventually devolved, especially now as we navigate COVID and remote work, into the primary method of knowledge transfer, even if it is an inferior tool for the job. At least this was the case at my previous company, and likely in many more.

I've left the enterprise world and landed myself at a tiny startup where PowerPoint isn't a skill they were looking for. This post is nothing more than a story of how PowerPoint drove me away from a steady product career with good pay, healthcare, bonuses and stock options at a company that will surely have a multi-billion dollar exit.

Don’t get me wrong. It’s not that I don’t like presenting. I fucking love it. And I love visual tools to anchor a presentation, keep it on track, and help transition between phases. My deck game is strong. I’ve had presentations that reached legendary status, where long time colleagues would bring it up frequently, ‘Remember that presentation from 4 years ago?’ I felt pride. I had a minimalist aesthetic with infographic style metrics, that were easy to follow, easy to read and compelling.

I might not even hate PowerPoint at it’s core, I just couldn’t stand where it brought our organization.

Maybe it was my fault. Maybe it was that legendary deck from 4 years ago that put people in a PowerPoint psychosis. Perhaps it would be this next meeting where they could unseat me from my PPTX throne. A rather gradual meeting evolution happened over the span of months, where increasingly it felt like you were being fired at by the PowerPoint cannon from all directions.

Even the most trivial check-in had a slide deck. There was this weight that followed you around. Who’s meeting is this? Who is responsible for the deck? Is it my meeting? I don’t think so but I’ll prepare a deck anyway.

On multiple occasions, I was in an a multi-department meeting, and realized that all other department leads had decks. I hadn’t initially thought it was required for a 15 minute check-in. Now, some bizarre one-of-us guilt had me creating a deck WHILE THE MEETING IS ONGOING! Absolute. Fucking. Nonsense.

And it was a race to the bottom as far as presentation quality, and applicable use-cases for PowerPoint.

Perhaps this was the most damaging to our corporate knowledge management. As PowerPoint became more and more pervasive, a meeting could only exist so long as a slide deck existed. The deck itself started to become the place where all questions, data, tasks and decisions were stored. Slide-show mode was rarely used, as a meeting was often oriented around making edits to slides in real-time with all attendees watching.

Suddenly, a large portion of our company knowledge-base became a series of .pptx files stored on Confluence. It wasn’t uncommon to have 50+ slides in a deck. If you couldn’t make the meeting, don’t worry! Someone will send you the 250MB deck, which will be a yard sale of watermarked stock images, a requisite 'easy button' image, changing bullet and font styles, bad copy/paste, pages of links to other decks, out-of-context data and embedded Excel files.

People say this. People say it all the time. They’re making light of the fact that their shit is so jacked on screen, that it makes you feel defective, because your brain can't comprehend what it's seeing. Like when the eye doctor starts to move you down the eye chart and you realize that it’s just an indecipherable blur.

This is where I start to drift off. Let me check my email, my todo list, anything to not stare directly at the slide.

I once had someone embed an Excel sheet into a slide that went up to column AB (that’s 28 columns) with 25 or so rows. He said ‘I know this slide is an eye chart, so it’s hard to read, but A1 says Metric. B1 says Department. C1 says...’ And he just kept going, reading the cells.

I thought we’d peaked, right there in that moment. There would finally be a reckoning. Things would get better after this. But someone out there, from inside the Zoom blackhole, was watching intently, possibly using an assistive screen reader. They piped up ‘In cell P12, it says 120,350, but it should actually be 130,250!’

So now, we stop everything. This can’t be. The presenter can’t see the issue of course, so we’d better hand over mouse-control to Mr. P12 so he can double-click on the embedded object and let us all watch him live-fucking-edit this Excel, inside of PowerPoint, inside of Zoom plus 50 more layers of abstraction.

This was it. We had hit peak PowerPoint. Or so I'd thought.

PowerPoint is not a collaboration tool. Sure you can add comments, and if you're lucky you can figure out how to review revisions, but when you involve more than a few collaborators, things get dicey.

At my previous company, there were certain quarterly meetings that required all departments to report out to the executive team. Inevitably we'd end up with 25 people creating their own acid-laced Napoleon's March to convey their department's status and contribution. On top of this, people are drawing color coded shapes to put on each slide to keep track of the status of the slide design process.

Before long, Microsoft's cloud sync would start failing for people and now local versions are being emailed around and someone (me) would be trying to decipher what's new and combine them, like a code merge without a diff.

I tried to change this process multiple times, to pull the data collection and story boarding process out of PowerPoint and into Trello, then lean on simple presentation tools like beautiful.ai to handle the presentation layer. However, because a PowerPoint file was a requirement as a document of record, and because all collaborators wouldn't comply with the new format, it fell on me to take everyone's 1500 word thesis and translate into a compelling set of slides. It was too much.

Everything you've read so far was frustrating, and hurt the company in many ways. It was often debilitating and demoralizing. But being tasked to use PowerPoint to track real-time project status was the point where I knew I needed to move on. As a product manager who is constantly juggling roadmaps, and having used dozens of killer Kanban tools, it hurt somewhere deep in the backlog of my soul to be using PowerPoint in this way.

Picture a slide with shapes as backgrounds, hand crafted iconography composed of a collection of ungrouped shapes, rectangular shapes as Kanban cards and text boxes on top of each card. Every thing was an ungrouped object, and each click & drag moved an unexpected object. If you spent a couple hours, you could clean it up so it was more manageable, only for corporate to issue a new flavor of the same template with a ‘’use this one” mandate, and the vicious cycle would continue.

When I should have been spending time in Jira, Pendo, Figma or Miro, I was spending it in PowerPoint. Once presented, my slide deck artifacts were filed away, to never be opened again. All that effort, for such short term value. The corporate benefit per hour worked on PowerPoint was extremely low, compared to other areas that generated a work product.

I’ve since moved on, with the intention of getting away from PowerPoint as a daily-use tool. I haven’t even installed Microsoft Office since starting at the new company. It’s liberating. That installation was one of the very first punishments of getting a new laptop that I experienced since Office 97. To know that I might be able to squeak by for a few years, perhaps the rest of my career, without installing PowerPoint, I’m downright giddy.

@sofuckingagile

I also hung onto this product through multiple acquisitions into much larger organizations. I became indispensable. I was the knowledge keeper. I knew where all the dragons lied. I new where all the compromises had been made. I knew the ‘why’ of everything.

It was suffocating.

It took far too long for it to click in my brain that I was stuck. There was no career path. Sure my title changed, pay went up, but my day-to-day never changed. I was so busy collaborating with dozens of people across all departments, that it felt like I was growing. I wasn’t.

There was a frequent situation that occurred that clarified my position. It wasn’t unique; it happened several times a day. In this case a member of our implementation team pinged me over chat, ‘What happens when I [perform these steps] in the application?’

The thing was, I knew, but I strongly felt as the enterprise implementation team, they should know the most about app functionality. They should be the most fearless with bending the application to suit their needs. I told my colleague that they should try those steps to find out.

‘I’m on with a customer now, I need to know. Please tell me!’

I had been so responsive, so all-knowing, for so long, the entire org was conditioned to go to me for answers instead of discovering on their own. And suggesting otherwise was met with hostility.

I was a crutch. I was a shortcut. I was a wiki.

In enterprise SaaS, things can be complicated. There’s potentially hundreds of product configurations and dozens of integrations, personas, and use cases. After realizing that I was a sentient wiki, I started to recognize that anytime a customer wanted to go beyond the core fundamentals of our products, I would get pulled into the implementation calls with a customer.

We had documentation, lots of it. We had involved all teams in the design process, the roadmap, the documentation. We did all the right things. But an enterprise customer is full of surprises and because I’d seen so much, I was rarely surprised and this was exactly why the products were configurable and extensible. It’s not that I didn’t want to engage with customers at this level, but I just didn’t want to get assignments in the implementation project. Inevitably, I would end up in a place where I was getting asked by implementation managers for the status of my implementation deliverables. I was becoming a shadow implementer.

There was a time, that I was doing deployments of our flagship product. This was back when we were a company of 15, and we had no deployment pipeline. It was literally copy/paste of directories across server farms and running SQL scripts. I knew a lot about the database and the application dependencies. But 5 years later, at a company with 600 people, a product leader like me had no business touching production servers and had absolutely no access. We had a whole DevOps department for that.

About monthly, I would get urgent pings from the DevOps team asking me to answer questions or respond to tickets that I would normally go to them for.

It was starting to feel like there was a 301 redirect on all product or infrastructure questions that went straight to me. This even seemed to survive after an entire department churned, like day 1 of onboarding for new employees included a training video called ‘Everything you need to know about Product X, Just Ask @SoFuckingAgile’.

My situation started to get dire. I had a hard time thinking strategically about product. I was too busy supporting the entire organization on all things related to the product. I was starting to get uneasy about building anything that required implementation effort or that was highly technical.

This included all integrations. In B2B enterprise SaaS you MUST integrate, so this was problematic.

I’m someone who likes to know. During product discovery and build phases, I like to understand the parts. But I had to stop understanding. I would coordinate the meetings to bring parties together to define the requirements, to understand the gaps and technical details, but I would not attend. I would not participate in testing or even demos of the new integration. I would not know anything about how it worked beyond the marketing slick.

This was huge. I could legit say ‘I don’t know’ to all questions, and redirect people to the correct resource. If that resource didn’t exist, it was escalated to someone other than me. Yes, our organization didn’t really empower people to take ownership of things and really become experts, but I was also enabling this by solving problems that I shouldn’t have.

Countless times someone would message me directly for product or industry info. Sometimes hours or weeks later, I would get the same question from someone else. I was constantly repeating myself and pointing people to the same documentation or resources.

One thing I instituted that helped was a specific Teams channel called Knowledge Transfer. Any questions that would normally have been DM’d to me could be posted there, publicly for all to see. In theory, others could step up to answer these. I could also forward DMs there to respond to publicly or refuse to answer in DM and require them to retype their question in the Knowledge Transfer channel. Rarely did others step up to answer, but it became more like a SoFuckingAgile office hours, which was still a big improvement.

Sales reps were needy. They always wanted me on sales calls like some sort of safety blanket. The thing was, their department leads had no idea this was happening. I created an email rule where any email to me from a sales rep would be auto-forwarded to sales managers and directors. Then they could decide if I was required on that call. This was extremely helpful.

Quarterly, I would also train other department managers on the most glaring knowledge gaps on their teams. I would help them build new content into their new hire onboarding programs. For example, if I got sales reps asking about prospects needing SOCK TWO (lol), the topic of SOC certifications and other data protection discussions would be added to the training list.

Even with some new measures in place, I was the bottleneck on everything in the product line. My entire work day was clicking Start Meeting buttons, not knowing what I was going to step into, and having the pressure of all those people who were there thinking I would be the one to drive them forward on some task. I’m not a micro-manager. I know a lot of people who wished that I was, but I really dislike getting involved in leading projects unrelated to getting products out the door — things like price increases, outsourcing professional services, branding etc. I would give big hints like ‘This is very similar to [insert identical project we just went through] and I think you should use that as a reference to move forward.’ It was draining and repetitive.

Being indispensable is possibly good for job security, but I had stopped learning. It had been years since I’d learned anything new from my work or the people around me. Sure I’d learned new ways to try and help people be more self sufficient, but the impact was minimal. I was stuck. One of the biggest problems with being indispensable and announcing that you feel stuck, is that the business will take steps to get you even more stuck, through more money, shinier titles and stock options.

This is more of a cautionary tale. I never really found out how to get unstuck and remain in the organization. Just know that it can sometimes feel nice to be an expert in something, but it’s a possible trap that can stall your professional growth if left unchecked for too long.

@sofuckingagile

Mental health is a major concern in the tech scene and a recent post of mine about acute mental health issues camped out at the top of HackerNews for a while. In the comments were countless stories of breakdowns, suicide attempts, mourning and a general state of mental unhealth.

Talk to anyone in software or technology who’s in their 40s and they just got back from leave, they’re on leave, about to go on leave or they just quit their job and are laying low. They’ve burned out. The path to remaining in technology by your 40s was risky one, where you lived at a breaking point continually without any help and no template for even discussing mental well being. Nobody was watching out for us. Everyone just piled on. Nobody asked us how we were doing. Not ever. Until now.

I’m so impressed right now. This is being taken seriously. This new generation is on it. Everyone is talking openly. Their trauma is known and well documented. Help is there, techniques and models of mental well-being are studied and frequent check-ins are are keeping it top of mind.

This is the way and it’s long overdue.

I find this one almost adorable. Nearly all of my colleagues suffer from a serious case of imposter syndrome. They’re moments away from being found out. Someone is going to confront them, ‘AHA! I KNEW IT! YOU DON’T KNOW WHAT YOU’RE DOING!’ Guess what? I’m still waiting for that too.

I tend to rely heavily on pattern recognition and learned shortcuts. If you’re earlier in your career, you don’t have as big a dataset to draw on those patterns and devise shortcuts. But here’s what I’ve learned about my colleagues. They sure as hell can use first principle thinking to work towards solutions. Breaking things down to their component parts, understanding problems and remixing into new solutions is a definite strength. Put another checkmark in the impressed column.

One thing that I try to remind everyone who suffers from imposter syndrome is that, for your role, in your product category, you’re one of the few experts in the world. You do know best. You’re an expert in this specific thing. This applies to almost all roles. Let’s say you’re hired as a Associate Product Manager for a digital signature platform. By the time you’re done orientation, you’re already more expert than most of the world. After a year, you’re in an elite category of experts on that market and product space. Embrace it and remember it when doubt sets in.

I’m a little broken. I’m skeptical. I don’t care about the latest buzzwords. I don’t care about the hot new methodology. I don’t care about the latest business book and the groundbreaking framework. Show me your revenue chart and all the ways the buzzwords influenced it. Show me how your buzzwords retained your team and let you spend time with your family instead of working every night and weekends.

I’m broken in so many ways. Partly because of years of internal politicking, managing up, being thrown under the bus, seeing sales quotas pulled out of thin air, finding release dates magically changed in board decks, grinding on RFPs to find out they’re rigged or solving the same problem a dozen times.

My colleagues aren’t yet broken and it’s rubbing off. Work is exciting again. It’s still hard as hell, but all the problems seem solvable. The world of software development is still just as broken as me, but the next roadblock doesn’t seem like as big as a slog since we have only momentum at this stage. Inertia isn’t in our vocabulary.

;)

Listen, I came up through the entire evolution of emojis. From emoticons, fucking wingdings, all the way up to unicode. For me, emojis were something used in private speak, over sms with friends or in chat rooms online. You would never use them in corporate communication, or in marketing copy. Things have changed and it’s pretty cool. My colleague’s emoji game? 💪.

When everyone is empowered to just get shit done, you end up with content sprawl. Grab the tool that’s easiest for you in that moment of go for it. This is an absolute blessing when you’re a small team. As a new hire though, it makes it hard to find the source of truth, because there often isn’t one.

My philosophy on this — if there isn’t a source of truth, the content isn’t likely important enough to hold on to. I’ve found lists of product ideas in Notion, Jira, Asana, Airtable, Google Docs, and Miro. Some overlap, some don’t. If you start at a new job and find something resembling a backlog in many areas, for your own sanity, thrown 90% of this out. It’s most likely a good idea to throw anything out that hasn’t been updated in a couple months. In start-up time, after a couple months it’s old news and no longer relevant. Don’t treat it as precious. Good ideas will return if they’re good.

The content sprawl was created in the name of efficiency, but the reason you documented it was so that you could easily leverage it later. That is, if you can find it. Sprawling content leads to re-inventing the wheel several times over. I swear we listed out our beta launch plan somewhere? Oh well, I’ll just restart it over here. As your team grows you definitely want to centralize knowledge, and avoid wasteful cycles searching for and re-creating content.

I’m only 4 months in. We’re in the middle of a pretty hard pivot in product direction, but the core market thesis remains the same. Similar to my career, it feels like a Re-MVP, where we adhere to the same vision, just a new approach on a new tech stack. The whole team is fantastic, excited to embrace change and looking out for each other. We’re at the start of a fantastic ride. 📈

@sofuckingagile

In my earliest days in the software business I wore a lot of hats, and one of them was support. I fully understood the condition of a user and how frustrating lengthy support ticket lifecycles could be. As I moved into the product management space and worked side-by-side with engineering teams, I saw how tickets with virtually no useful info would get thrown over the fence which the expectation to ‘fix it.’

The other nuance of software support at B2B enterprise SaaS is that the support team is nearly always new. It’s often an entry level position, where people will start their careers. They’re on-boarded in a couple days and are thrown into the fire. Troubleshooting is typically very shallow, often done via chat and rarely gets more technical than clearing your browser cache. Also, if you’re any good, you move out of front line support very quickly.

People use different words than you to describe things they see on screen. Something that you call a menu might be a droplist to someone else. Not every user knows all of the lingo and info necessary for you to support the application and they don’t even know what parts of what they’re seeing are the most relevant — a screenshot is universally helpful. Most of the time, we don’t even know what’s relevant but let’s always get the most information we can, in a way that’s least painful for the user.

Your users will also lie to you. Not in a malicious way, sometimes they just don’t know.

Support: are you using Chrome?

User: yes [they’re not]

Support: when did this problem start happening

User: Just today [it’s never worked]

A web app I was involved in had a mobile web app which had some advanced in-browser barcode scanning using zxing. For our own sanity, we supported only Chrome and Safari on mobile devices.

One of our support reps pinged our support channel saying after scanning a barcode the customer was directed to a blank page and of course they could not recreate the issue. I asked for a screenshot but was told, ‘he says the page is blank, he’s on Android, running Chrome so it’s supposed to work.’ I was adamant to get a screenshot.

The left image is Chrome and the right was some flavor of Samsung’s stock browser, which was not supported.

Within a moment, we knew what the problem was. They were not actually in Chrome, they were in the stock Samsung browser. If we relied explicitly on what the user had said, we’d probably still have this one in a bug queue. It’s more than seeing that one browser looks different, it’s knowing that there’s different browsers and the fact that browsers do behave differently. Without the screenshot, we’re completely lost.

The user didn’t have Chrome set as their default browser, but they had it installed and were using it. However, recently they’d clicked an email notification from our app, which loaded the default Samsung browser instead of Chrome. The fix for them was simple, set Chrome as the default browser.

Had we not gotten this screenshot, here’s what would have happened.

The screenshot saved us from this horror. On mobile you can usually ask Siri or Google Assistant to grab a screenshot. On some devices there’s button combinations. On windows you can do windows key + S-N-I-P to launch the Snipping tool. On Mac, Shift + Command + 3. Heck you can even grab your phone, and take a picture of the screen on another device.

Always get the address bar in the screenshot. The address bar can have wild and unexpected info.

I have no idea why this happens, but people do the wildest things and uncover rare edge cases all the time. In the enterprise software space, you will encounter users who are required to use your web app at work, but have limited web experience otherwise. This is where you'll be confounded with the weirdest things.

In many browsers, you can save the entire webpage locally, through some sort of Save As which downloads the site contents and gives you an html file to run it. Many users mistakenly do this when they think they’re creating a desktop shortcut. Then they run this shortcut and get something that looks like your web app but it’s 100% broken.

A support ticket like this is brutal because it’s not even close to being on the list of things a typical support rep would consider. The answer is in the address bar.

In some enterprise SaaS environments, it’s not uncommon for clients to have some sort of playground or test site. It’s like a mirror of their configuration and data at a URL where they can train and practice without impacting their live implementation.

At my last job, we once issued playground sites for all clients who attended our user conference. There was lots of fanfare around this. People loved having these. Now months went by and a client kept telling support that other users in his org can’t see the updates he’s making. He’d bookmarked this playground and had been logging into this mistakenly as his live site for several weeks.

There was a lot of effort put into this ticket and the user suffered for many weeks and all it took finally was to get a screenshot to the product and engineering teams that included the address bar.

Real-time screensharing is the holy grail of simplifying support. If you don’t have a specific remote assistant screenshare tool, get a user on Zoom and have them share their screen and do a voice call. This is the best way, especially when you can see their entire computer display. Here you get the full experience including knowing what other apps they have open, you see their system clock which can also help with bizarre support issues, as well as their dialog of what they’re doing. They can even hand over mouse control. If zoom isn't possible, have them grab their phone, point it at their computer screen and record a video.

I even once HEARD the answer to our problem in a screen recording. A client was getting duplicate and sometimes triplicate records. This was reported off and on for weeks. It was only this user, which spoke to a device or workflow specific difference. I urged support to get a screencast of her workflow on this page. They sent the video saying everything seems normal. The client had used her phone to record her computer desktop. I turned on the volume and heard the problem. She was double-clicking something that was expecting a single click. I heard the double-click. In the front end we weren't disabling a button while a transaction was running, so she was able to double-click thus posting her transaction twice.

Seeing a recording is even better because you can often get the steps to recreate the issue. It used to be that asking a user to join a Zoom was a regrettable blackhole of further support.

But now, thanks to the pandemic, almost everyone knows the mechanics of zoom and this is now a reasonably painless experience.

The phrase a picture is worth a thousand words is true here. A picture also saves a hundred days, reduces painful meetings, protects from churn, and makes for a better day for all involved. Get a screenshot.

@sofuckingagile

This could look something like:

A definition of done helps with planning, reduces arguments about the backlog item and can ensure that teams not working directly on the item know when it’s their turn to spring into action.

In many cases, a fully resolved definition of done means we get to ship our code to production! Our clients will fist-pump, rejoice and immediately start jumping on the new feature! Our prospects will stop evaluating competitors and sign their orders!

Not exactly.

The problem is, each of these checklist items on our definition of done has no definition of done. We tend to get it twisted that because we put checkmarks in all the boxes, that we’re really going to nail this for our customers. Your definition of done is not about that.

There’s so much risk in the software development process, especially if you have a thousands of users. If you blindside users with a workflow change without proper docs or communication, they’ll be pissed. If you don’t do performance testing and suddenly you introduce a slow blocking query, you’ll create a bad day for your company and your customers as well.

You’ll still fuck up and miss things. That’s a fact. But at least you can point to the definition of done and know where the gaps are and how to improve. You can reduce internal conflicts just by saying, ‘You know our definition of done that we all agreed upon? Turns out, it wasn’t done. There were gaps. We’re fixing it. Here’s what we’re adding.’

Like all things in the world of technology, everything is a work in progress.

Here’s a good example from a previous product I worked on.

We had introduced some new product on-boarding walkthroughs. These had passed all definition of done criteria. They’d been rigorously tested. Everyone knew they were launching. Marketing, sales, support, everyone knew. Except implementation. Somehow, they weren’t explicitly told. Not that big a deal we thought; these walkthroughs are designed to make their lives easier! Except, unbeknownst to the product team, they used some browser automation to automate configuration of new client accounts. The new on-boarding guides were disrupting this automation without anyone’s knowledge leading to many false starts with client activation calls.

When our implementation team leaders came barging in, we could point to the definition of done, show where there was a gap, and discuss the plan to sharpen it. In this case it was as simple as adding a notification to the implementation team and logging record of acknowledgement explicitly. We dramatically reduced the time spent arguing and got immediately into solutioning.

It’s probably 20% done according to your users. This is completely OK. You may have done tremendous due diligence on the product discovery, but you never really understand the problem you’re solving until release date, so build into your roadmap some extra effort to build v1.1, v2.0 and vNext of the feature. Now that you’ve announced this new feature, you’ll finally get truthful feedback and can move forward with refining. This is the premise behind MVPs to some extent and it’s a meaty topic worthy of it’s own deep dive in a future blog.

@sofuckingagile