[lukethomas]

I knew we needed to build a suite of tooling, as our goal was to be a "hub" for the most important stuff at work. In retrospect, we built too much product.

If I start another company, I will spend all my time focused on solving a very big pain-point with a few simple product.

With Friday, I wanted to keep the product simple, but the people we talked to always were talking about the "yet another tool problem" - so there was a desire to consolidate. How I interpreted this was that we needed to build the "suite" vs. spending all our time on one feature.

I could go on and on about what I would do differently, but I'm thankful for the opportunity and have learned a lot that will (hopefully) make me more effective in the future :)

[pathartl]

> In retrospect, we built too much product.

This answer is so generic, but so apt. Everyone can throw around phrases like KISS or MVP or try to implement methodology like agile, but it's so hard to just identify _what_ you want (or need) to build.

We're looking at a major revamp/rewrite/refactor of our main product that previously had been built with the idea of being able to solve every problem our customers face. This decrepit, aging codebase has so many bandaid fixes for every conceivable "what if" scenario that it's just become unmaintainable.

[nerdponx]

Maybe the "yet another tool problem" can be addressed by making your tool easy to integrate with other tools, rather than trying to build a big all-in-one suite.

[lukethomas]

This was precisely our approach, but we built our own features for the "gaps" that we believed existed in the other products.

If an existing app was doing a decent job, we didn't want to compete with them. The issue is that we ended up arriving in this "dead-zone" where we didn't replace an existing tool and pull budget from an existing category of tooling.

[mdip]

It depends on if their target audience was small companies or enterprises. It may have made a difference, but it wouldn't have changed much for Enterprise customers. At BigCo (a global telecom[0]), it was much easier to add business from a vendor that we already had a relationship with than it was to purchase anything from anyone we didn't. It was also, of course, much easier to buy software/SaaS from one of the existing, boring, established vendors than lesser known/smaller ones. There was a mess of "Purchasing" involvement, legal, and everything else just to set things up so we could make the purchase. I don't know what Friday was for (had never heard of it until, today), but it sounded like it was something that would be company-wide, probably, so sneaking it in with an "expense card" isn't likely going to be defensible.

Then there's the "easy to integrate" side. Expect it to have to pass security reviews if it's SaaS of any kind and will touch any of our IP[1], and particularly detailed ones if it's very easy to "integrate with."

Azure AD Login was easy for us at "BigCo", but tied up several days of more than one grumpy security architecture team member's time with a variety of pen-tests that are required before they'll grant approval for it in our domain. That goes up exponentially to the impossible pretty quickly if it wants permissions to access things on our end via OAuth grants; even things that are typical (profile photo).

IT Architecture might get involved if there would be a need to make sure it worked with our systems, minimally to set up monitoring for it if we're making it available to a large amount of staff because if it goes down, we'll get a million calls into our 4-6 person (state-side by contractual/security requirements) Help Desk over something we can't do anything about and we're going to make sure we have a way to react to it when that happens. Someone's going to have to learn how to do any administrative/integration requirements, because configuration changes, we merge with companies somewhat frequently, and someone's going to have to make sure they know how to set it all back up, correctly, later -- just in case -- even when it doesn't make sense. Likely, BigCo want it to be used, so someone's going to have to write copy for an article for the company landing page explaining what it is, how it works and what problem it solves. There'll be other activities related to this when adoption doesn't take off. IT will have to dedicate some time to tracking usage to make sure we're getting ROI on it when the quarterlies come around and they have to justify every recurring expense, including the ones outside of the sticker price, all over again, and it's easy to trim off the add-on. Plus, they're often the ones who take the budget hit in the first place.

Legal/HR/The Business(tm) might get involved if employees can communicate, uninhibited, through it -- just like they do with E-Mail while they apply a flobbidy-jillion set of restrictions/disclaimers bits of nonsense around. We were not a Defense Contractor, we were just big, spread out and had a lot of employees. At scale, you end up with increasingly many who lack common sense, and a small fraction who still need to be warned about Nigerian Prince scams when one slips through. In a strange alteration of Rule 34, someone will upload porn to it or store porn on it if it is possible to store things on it. For the person who wants the product, it's going to be requiring phone calls, follow-ups, and general "going to bat for the vendor's product" against a hurricane-force headwind.

In fact, an add-on might be less likely to be purchased -- by BigCo, anyway -- because it doesn't do enough to pass the "Why do we need to tie up all of these people to bring this easy-to-integrate product into our environment when they can just use (some terrible excuse for a thing by comparison)?" The "we don't need that bad enough" answer is usually the case for Add Ons, and having a number of ancillary capabilities to distract with sometimes makes it more attractive to "the business" side of the above groups, which has the ability, often, to over-ride all of the rest of the "No"s going around.

At BigCo, an add-on requiring anything that the "good enough to somewhat OK" solution/solutions we already have kind-of sort-of covers doesn't stand much of a chance of being purchased. The one thing that can get in the door is the simple solution that solves a big problem, especially if there's nothing else out there that much of any part of it from any of the big vendors. I spear-headed a small handful of those. It has to be amazing and some reasonable combination of inexpensive, simple to maintain, highly available, non-critical if down (many, many things are unexpectedly critical).

[0] I worked there about a decade for 17 years, incidentally, most of it remote at an organization that was notoriously against remote work ... basically against a major service we enabled and often provided for other businesses. I worked as a software developer in the architecture organization working primarily on security-focused projects (figure that out) and had to go through this process enough to make my soul die a little.

[1] Basically, everything. At least, anything that would have a reason for the company to purchase it.