When we think of startups, we frequently make the mistake of automatically assuming that we’re talking about tech businesses. It’s a fact that many startups are technology-driven companies started by entrepreneurs who, in addition to an appetite for risk, have a background in software engineering. In businesses like this, at least one of the founders should be an engineer lest they face a task orders of magnitude harder than their engineer-equipped competition.

Being innovative in a certain domain requires a certain understanding of that domain. This truth becomes even more evident in areas that usually require years of education and experience to become a master.

You would be at a disadvantage starting a textile business without knowing a little something about fabrics and sewing, although you might be able to get yourself off the ground with enough dedication and time. You would be kidding yourself if you started a company to manufacture carbon nanotubes without a formal education in chemistry.

But luckily, for the rest of us entrepreneurial folks who don’t code, sew, or remember Avogadro’s number, there are lots of businesses that involve implementing technology, but are driven by business innovation and not hardcore technological innovation.  In these businesses, where progress is the result of new ways of thinking about old problems, fluency in HTML is less important that being able to clearly communicate requirements to people who are fluent in it.

In many areas of business, particularly the highly-regulated securities markets, the narrow constraints of those regulations prevents even the most innovative, creative, disruptive engineer from leading from the front. (Whether that’s right or wrong is the subject of a different post.) In spaces like this, a business is better off with founders drawn from related businesses than a killer software developer.

For the past few days I’ve been listening to an incredibly good podcast called StartUp. Its made by Alex Blumberg of Planet Money fame, and in it he documents how he’s building his own podcasting company. Its an amazingly personal and nearly realtime view into the process of forming a company, raising capital, and having a family.

Episode 7, “How Listeners Become Owners,” goes into detail on Alex’s discovery that despite the JOBS Act being signed into law in December 2012, non-accredited investors still are unable to actually make investments in privately held companies that fundraise publicly. The intention of the lawmakers is good – to protect folks who don’t have a background in finance from making risky decisions and losing all their money.

The problem as I see it is that individuals who aren’t accredited investors have plenty of other insanely risky ways of losing huge, unlimited amounts of their money on all sorts of things, including government-operated lotteries. The notion that individuals shouldn’t be able to choose to put money into risky opportunities as a way of making returns is silly and paternalistic. Anyone who says otherwise but fails to similarly condemn state lotteries, private gambling enterprises, and public securities exchanges is a hypocrite.

I don’t dispute that people with good intentions are trying to figure out how to prevent people from being swindled in private stock sales, and I do think there is a role in this space for regulators to guide the process. But the current rules are simply not working, and are in fact preventing lots of educated people from making informed, rational decisions about their finances.

For example, a hypothetical economics professor at a small university is unlikely to meet either the income or asset requirements under current accreditation rules, but is likely to be a person entirely capable of evaluating a risky investment opportunity.

This person can, under current law, open an eTrade account and put every dime they have into a huge variety of risky securities. Or go to Atlantic City and put it all on black at a roulette table. Or buy a huge pile of MegaMillions tickets (odds of winning $1M are 1 in 18,492,204; the jackpot is a ludicrous 1 in 258,890,850).

But they can’t put $2,000 into an early stage company until the SEC finally gets moving on adopting Title III of the JOBS Act, which is the section that allows non-accredited investors to participate in publicly solicited securities offerings. Until this happens, small investors aren’t being protected from risk, they’re just being shut out of opportunity.

I recently came across a couple of really old blog posts on MSDN (Seth Eliot, Scott Louvau) talking about the benefits of being a test developer. The posts reminded me about the Microsoft engineer career trajectory, which – from what I understand – often begins as SDET (Software Development Engineer in Test) before graduating into implementing new features.

I got to thinking there could be advantages to applying that template to young product managers.

One of the hardest things to get used to doing as a new PM is thinking about dependencies and edge cases. Coming up with new features and defining how they’re supposed to work is a fun and creative endeavor. Coming up with how users are going to intentionally or unintentionally break those features is not so much fun, and actually trying out these behaviors can be, with apologies to my friends in QA, mind-numbing drudgery.

The value in testing, however, goes way beyond just verifying the feature. Being forced to try out the same test procedure in three browsers on four OS configurations as well as tablet and mobile setups gives me a chance to really think about how the user is going to experience the feature. Being forced to fully immerse your brain in the feature also gives you me chance to have a eureka moment about what else is impacted by the feature.

In addition, starting a new product manager out by having them perform user acceptance testing on new features and regression test on old features could be a great way to get them fully immersed in and trained on the product.

Think of a complex system that you’re familiar with. In the next five minutes, explain to me how it works.

The point of this question is to figure out two core things: is the candidate truly familiar with something they claim to be an expert in, and are they good at articulating complex ideas to people who may not know anything about them.

I recently asked this question to a frontend developer candidate. He claimed on his resume to be an expert in WordPress, something with which I have more than a passing familiarity.

His explanation was not so good. He instantly became very jittery and gave me a rambling, incoherent explanation of the popular CMS. Although technically accurate, it barely scratched the surface of what WordPress is for and why I should care about it. He was a really nice guy, and I think his technical chops are probably average-to-strong, but his failure to satisfy the question was a huge red flag for me.

The role he was interviewing for was to be the only frontend resource on a team with a handful of backend developers. His ability to clearly explain the frontend technology to the backend folks would be critical to his success or lack thereof. It could have just be interview-specific anxiety, but my product’s success is too important to roll the dice.

Another candidate for the role answered the question with an excellent explanation of a complicated embedded system that he had built. In addition to checking all of the other boxes, he was great at explaining the system and why things worked the way they did, and he was able to do it in a tight timebox (five minutes). Hired.

As a product manager, when I interview a developer candidate my role is not to check if they know the technology they claim to, but rather to get a sense of personality and leadership qualities. Asking them to explain something complicated to a person who may not know anything about it can tell me something about both.