Sunday, January 26, 2020

Do I have a product here?

Sometimes I chat with people who are interested in starting a side business, or even leaving their $dayjob. That can be a really rewarding option if you’ve got the opportunity. Of course, there’s nothing wrong with not doing it! Some people simply don’t want to run a small business along with doing the value-adding work which brings in the money.

But if you’re willing to take on being your own boss, how should you evaluate if you’ve got a product that can float that business? Let’s work through a system for finding that answer.

Step one: Give yourself an hour per day over a week or two to do some research. You’ve got a blank sheet of paper and an idea, so let’s do some calculations and see if they can pencil out.

  • What would it cost to pursue the idea?  Do you need tools? material? People? Do you have to get certifications or build up a reputation before you can get those things? What does it cost in money and time to get to the point where you can start? What does it cost to continue operating once you start?
  • How much money must you make by what time to make it worth pursuing? Do you understand your budget? Have you considered what could be reduced and what is non-negotiable? Be honest here, if your minimum bar for quality of life requires excellent espresso every day, don’t budget for a can of Medaglia d’Oro.
  • Can you identify champions who will use your idea, gatekeepers who will allow it, buyers who will pay for it, and budget that exists today? This model is commonly used in business-to-business enterprise sales, but it’s not bad for considering any product transaction. Even if these roles are only different voices in a single consumer’s head, they will absolutely play out their functions. Consider your own purchase of a game: does your internal champion want the experience of playing it, does your internal gatekeeper approve (“what would my friends and family say”), and can you afford to buy it?


Step two: Assuming all of that pencil work comes out with a positive answer, you’re looking at refinements. Now it’s most interesting to consider: how much time will it take to prove or disprove that back-of-envelope estimate? Can you take a vacation from $dayjob and spend it on this idea? Hint: if that sounds terrible, you’re probably not going to like being your own boss. This part may be really tough because you’re going to need to validate your assumptions: talking to salespeople for quotes, talking to prospects, perhaps even asking your friends and relatives to invest. If you haven’t sold before, this is where you start learning, because if you can’t sell your idea to a friendly audience you’re certainly going to face some struggles with the outside world. In some software opportunities, it’s also necessary to ask: do you truly understand the technology that you intend to use? Do you need to spend part of this time learning to prototype your solution? Some people do very well in classes or seminars. Personally, I’d buy a stack of books and disconnect for a couple of weeks. Either is more weekends or PTO time from $dayjob.

Step three: If you’re now properly convinced you’ve got a product opportunity... how do you get from where you are now to where you want to be? How much money do you need to save? Are there trigger events or red flags you’re watching for? Now that you’re looking for the moment where you can commit to your new venture, you’re going to face additional stress from $dayjob, so keep an eye on mental and physical health.

Tuesday, January 14, 2020

Product Management Internships

An engineering internship program typically runs 6 to 12 weeks, often as a group exercise. Interns join scrums, 2-5 interns (generally 3), where there was a known deliverable on a topic of interest. They would experience the corporate version of their classes: understanding problems, sprinting to solutions, and presenting to the team on progress.

Problems to tackle will usually be areas needing investigation but not yet critical path for the business. Guidance comes from a team lead or senior individual contributor, who advises and runs a daily intern standup in addition to their team standup.

I’ve seen that program a few times. I don’t really like it... the projects can be poorly considered and don’t go anywhere, and the interns don’t end up understanding why the projects would or wouldn’t work in the real world. So it’s a lot like hackathons, only stretched over a summer instead of a week.

I’ve probably seen half a dozen force-directed graphs of data sets that could never scale at a real customer, along with a bunch of pointless dashboard re-skins. Not to mention solutions that could technically work but are not feasible in the company’s licensing model or data system.

What the interns do learn is process and culture fit. That’s not terrible, but a lot of it can frankly be taught in school instead. It’s totally wrong for product management. So how should our internships go instead?

Maybe this is regional, but in the SF Bay Area tech companies are competing for interns. You can win excellent candidates by showing why they’ll do real work which will ship. Intern wants to get a job. “Got to prove culture fit at $HouseholdBrand” is one path to that. “I shipped a feature at $Elsewhere and here it is” is another one. “Proved culture fit at $Elsewhere” is not so good.

Set that as table stakes and you’ve got a good base. Next, focus on how to teach product management. There are different philosophies for that, which I’ll touch on in another post.

Know everything, then automate!


The concept of virtual patching has set me off on a small rant.

If you’re not familiar, the concept is something like this: vulnerability scanners determine that PC42 in the CritStuff system has a nasty problem, but you can’t patch it for reasons. So instead, software magically figures out that exploiting this vulnerability requires access to port 80, and tells the nearest firewalls to drop anything headed to PC42’s port 80.

I’m down on two concepts here: the first is high risk automation. I have scars from network admission control. I’ve seen SEC filings delayed because of a properly quarantined laptop, never mind the attack ships on fire off the shoulder of Orion. Blindly implemented policy has high risk, and some knowledge of context is needed to make a proper risk-reward calculation. People aren’t perfect, but they’re better at this than software is.

The second concept I don’t trust is a requirement for pre-learning. Anything that requires the customer to learn in great detail how their systems work and what the dependencies are before they can safely act has put too much burden on the customer. Anyone remember host-based intrusion prevention systems? How about application virtualization? The environments that are simple enough to manage this way do not have sufficient resources attached to support a software vendor. Said differently, this approach has failed to find market traction enough times that it is now available as free open source.

One is supposed to argue that the virtual patching tool, like learning mode IPS before it, is able to save the customer the trouble of learning... except using those automatic tools just leads to learning about the dependency by accident instead, and therefore is still a market fail.

What about AI? What about it? A perfect robot would be more patient than a human but just as capable of learning the entire system, automating it, and maintaining the automation. But using that system would require the humans around it to either understand as well, or take a leap of faith. People will totally take that leap in order to gratify our laziness, but two or three failures will mean the system is rejected.  Can the robot be perfect? If not, can it be cheaper than a human? And is any of this conversation relevant to the far-from-perfect robots we can actually build today? Sometimes.