Category Archives: Software Business

Mitigating the Mitigations

The first step to dealing with project risk is to list mitigations—the steps you will take to avoid or handle the risk. But, don’t stop at just listing them.

The very next step should be to think about whether those mitigations themselves have obstacles.

For example, let’s say you have a project with a large mechanical portion, which doesn’t require communication or coordination to implement. If this work can be done in parallel, then adding engineers mid-way (once the a core has been established) could speed up the project, but even at the start, you must

  • Get budget approval
  • Find a source of engineers (contractors/internal)
  • Structure the work so that at some point it can be done without coordination and in parallel.

Projects like converting a lot of code from Objective-C to Swift or from an unsupported version of a framework to the current one work well for this. Projects that require a lot of cross-developer coordination are famously made later by adding engineers.

Depending on the stakes, it might be right to ask engineers to temporarily put in more hours, or to schedule time-off earlier in the project if possible. These things are easier to do if you talk about them earlier and gauge the impact.

A third option would be to clear off all other work so that everyone can concentrate on the high-priority work at hand. In that case, those projects have risks that need to be communicated to the project managers so that they can list and mitigate them.

It would be frustrating for a project risk to manifest itself, to have identified that early, and to have come up with an effective mitigation, which is not possible to do because it needed prior planning.

Software that knows ROI

Businesses adopt software for some rational reason. That reason is often expressed as a return on investment (ROI).

Based on the home pages of most software vendors, sales and marketing definitely know this. But based on the actual software, product development doesn’t seem to. Good software delivers ROI, but most don’t bother to tell you afterwards.

Decision makers in the organization care about this metric and will try to predict it before adoption and will probably track it afterwards.

And even if they don’t—if they were to magically know this metric, it would inform their decisions about renewal and increasing adoption. Sales and marketing lead with this info because they know that it’s a compelling selling strategy. They use ROI language in case-studies and may even have an ROI calculator on their site.

What I don’t see as often is an ROI calculator right in the software itself.

This is a huge missed opportunity. Lots of software has the exact data on how well it has achieved an ROI for you. That number is also a proxy for the ROI of the user that operates it or the decision maker that purchased it, so they would be very likely to want to share it.

SaaS products have a bigger advantage of not only knowing the ROI, but also being able to compare across customers and derive insights to why some customers are getting more benefit than others.

This information can drive account management calls, webinar topics, training, etc. Not to mention that the software could try to drive the user to those behaviors.

The model here to look at is Google Adwords. ROI literally drives the entire product UX and is reported on a line-item basis. It is deeply integrated into how you think of the product and adword metrics, PPC and CPC, have become common vocabulary in the industry.

So, what about your software? What is driving its value? Is that information readily available in the product itself? Does it drive user behavior? If not, how could it? Contact me if you want to talk more about this.

Tech Career Tip: Drive Revenue, Not Cost

I have spent most of my career in software product development, meaning the code I wrote went into the products that made money for the company I worked for. I did a short stint writing internal software for the organization itself and the difference was very stark to me.

When you write software for your organization, it’s often to automate something and the driver is cost-reduction. The problem is that cost can only be reduced so much and eventually you are one of the biggest costs (in a budget owned by someone who likes to cut).

Revenue, on the other hand, can be very outsized compared to your cost. The budgets for product development are often expressed as a percent of revenue, so success increases budgets.

And, often, product development jobs offer some way to participate in that upside (options, RSUs, etc). Getting equity from an IT developer isn’t as easy.

It’s more complex than just “for-sale” or “internal”. When I was in FinTech, I wrote products, but my peers at banks, writing internal software, certainly drove revenue for their employers and were paid very well through generous bonus systems.

Pay is not the most important benefit. When you are critical to how a company makes money, you have bigger growth opportunities, more respect, and generally more clout. Product developers at software product companies have career prospects that lead all the way to CEO. That is not often the case for developers automating internal operations.

Proposal Tip: Offer Choices

Most of my consulting proposals have options in them. I generally think that customers like having a choice in how to proceed, and it gives me a chance to express different ways I could help.

It’s hard not to have a preference for what they might pick. For example, you might want them to pick the most expensive option. I don’t always want that—sometimes an option is expensive because I don’t want to do it.

But, I find it best if I am neutral to their choice. I don’t want to be disappointed if my preferred option isn’t chosen.

In contrast, I want the customer to have a clear best choice. I don’t want them agonizing over the options, so they are usually pretty different. I might not know exactly which one they want, but it won’t be a close call.

For example, in an app proposal, one option might be to build the app. I don’t offer different ways I could do that, but I might offer to only be a project manager for an offshore team instead. Two very different options.

Each option is acceptable to me, but I think the customer would find choosing one easy.

In Your Personal Network, Be the Server

If you want to “network”, don’t think of it as trying to meet people, or trying to find customers. Think mostly of servicing the network you already have

Consider everyone already in your network to be your clients. This doesn’t mean “customers that pay”, it means “clients that you serve”. It means you care about their well-being. You would help them if asked. You are interested in them and their problems.

There are times when they make requests, and you would do it freely—do it and follow-up. There are times when servicing the request should cost money—make that clear.

But, the important thing here is actually care about them and their problems, not yourself and your problems.

Make deposits. Do this constantly. Do it right now. Just build up as much good-will as you can. Also, to be clear here: likes, shares, and engagement on social posts are not deposits.

What if you actually need something from someone?

Ok, at some point, you might a withdrawal. Paid work, a recommendation, an introduction. Some of those are small enough, just ask. Let them know what happened—follow-up.

For bigger asks, to the extent that it is possible, figure out how your withdrawal might also be a deposit. For example, can you ask your paid clients how you can deliver more value to them? How you can help their contacts?

If your mindset is to serve, you will constantly come up with ideas.

Communicating Salary in Job Postings

This is part of my continuing series on applying Jobs-To-Be-Done product design theory to the problem of recruiting. In my first installment, I explained the concept and gave some idea of applying JTBD to recruiting would mean:

In their workshops, Bob and Chris teach how to find out why people switch from one product to another by interviewing people that have done it already. How many of us have interviewed our recent hires to find out why they switched from their old job to ours, how they found out about it, what happened in their lives to cause them to want to switch jobs? If we did that, I think we’d find that we’re advertising in the wrong places, not emphasizing the right strengths, and generally not making the applicants know that we meet their hiring criteria.

Next, I wrote about the problem of hiring passively looking developers, where the key question I addressed was: “What would you do to your recruiting efforts if you wanted to hire people that aren’t looking for a job?”

Following along that vein, and again, using JTBD techniques, let’s talk about “progress making”. Essentially, people switch (products, jobs, houses, etc) because they are trying to make progress in their lives. In order to design products that make people switch to them, we need to know what kind of progress our users are trying to make.

In this case, it’s pretty uncontroversial to say that our potential applicants are looking to make progress in their compensation, or, if they are willing to trade that against other things, they have a lower limit.

Salary, for a potential job switcher, hits all of the forces of progress making.

  • They are pushed toward switching by the feeling that their current job doesn’t value them enough;
  • they are pulled toward switching by a job that pays more;
  • they are pulled back from switching by familiarity with their current pay structure and raise schedule;
  • they are pushed away from switching by anxiety that other jobs won’t pay as well (or have less potential for future salary growth).

Dissatisfaction, aspiration, allegiance, and anxiety: to get someone to switch we need to address all of these, and increase the first two while lowering the other two. (learn more about the forces from JTBD Radio).

Our potential applicants have total knowledge of their current salary, so to help people realize they will make progress, they need to know what we are offering. For the passive looker, who is not willing to invest much in each opportunity, the risk of early filtering is high. The unknown feeds the anxiety component and does nothing to drive aspiration (the two forces our offer directly controls), so they won’t associate “progress making” with your job description.

[ASIDE: I know why we don’t list salary in job postings, but I would say that whatever those reasons are need to be balanced against wanting to make our job attractive to top developers, which we believe are not actively looking for a job. So, if we accomplish “having a good starting point for negotiation”, but not “attract top developers to applying for our job”, we failed.]

To alleviate anxiety about your offer, I would try social proof, a lossy communication channel, or possibly a transparent salary ladder.

For social proof, get candidates via referrals from your employees. People will make a judgement about your salary scale based on what they know about their contact.

By lossy communication channel, I mean a way to communicate salary possibilities such that the candidate gets an idea, but knows that it might be wrong and doesn’t interpret it as an offer. One way to do this is with a 3rd party recruiter — you give them a range, and they will leak it to the applicant, who will have skepticism for anything a recruiter tells them. You could try 3rd party ads that “estimate” a salary or write up truthful descriptions in something like GlassDoor or other salary reporting places.  No one thinks those are definite, but at this point, they just need some idea.

A third option is to have total transparency and a completely non-negotiable salary ladder. This is what union and government jobs do (so it has a bad rap), but I’ve seen tech companies try it — here’s a really old post from Joel Spolsky about Fog Creek’s compensation and here’s a very recent article about Buffer’s compensation policy. Both use a formula based on mostly objective criteria.

Your goal is to throw something out there to alleviate anxiety enough to get them to contact you.


You rarely see an ad that is so good that it would be missed if it was removed. It’s not easy, but if you want to shake things up a little, look at one of the publications you advertise in and think about what it’s missing, then buy space and add it.

My favorite example of this is the PC-Lint “Bug of the Month” ads that ran in Dr. Dobbs and C++ Report. These were essentially the puzzle section of these magazines, and I used to spend time engaging with the ad each month. Solving the puzzle gave you a visceral understanding of what the product did.

You have to be careful. The other way you see this tactic being used is to make fake content that tries to trick the reader into thinking they are reading another article. I never think it’s a good idea to start off a relationship with such a blatant lie.

The better way is to be clearly an ad, but still have compelling content.

Some ideas

  1. Puzzles, like PC-Lint did. The trick here is that solving the puzzle should be a little like using the product. Just putting a Sudoku in your ad space probably isn’t going to cut it.
  2. Comics. For example: SourceGear ran a serial comic a few years ago.
  3. Pure educational content — don’t make it look like the publication, instead make it the text of your first auto-responder. It should deliver value
  4. Information. I’d look to Kinvey’s Backend-as-a-Service ecosystem map — I don’t know if they advertise it, but if they did, I would probably tear it out. If it was updated more often, I’d eagerly await the magazine it was in to get an updated copy.

The key is that it should add value to the content it’s delivered in. Hence: the addvertisement.

Four interesting tech jobs in the Pioneer Valley

I’ve been doing some research on how people advertise tech jobs, and I found a few interesting jobs in the Pioneer Valley that I want to share

  1. Fiksu: This company has offices in Boston and Northampton (right in downtown), and has an opening for a Software Developer in the Northampton Office.

    Fiksu, Inc. is a progressive, creative, fast growing, cutting edge
    advertising technology company for mobile applications.  We build the
    leading user acquisition platform to help brands achieve their
    business goals faster and more efficiently than ever before.

    Fiksu is looking for talented developers with a deep interest in big data, distributed systems, high scalability, open source technologies, and cloud computing.  You might not have much experience, but you’re a disciplined software engineer who is excited to learn and use new technologies and methods.

  2. Communicate Health: This company is right down the block from my house — I pass it every day. I met their Senior Designer, Molly McLeod, at the Western MA Hackathon, and she posted this job recently:

    Senior Web Developer
    CommunicateHealth, Inc. is a health education and communication firm specializing in improving health literacy through user-centered design, policy, research, and content development. At CommunicateHealth, we believe people deserve clear information about their health. This doesn’t mean using short words and lots of pictures — it means making sure the information and services our clients provide can be accessed, understood, and used by the people who need them most.

    The senior web developer will take the lead on many projects as our primary technical staff member.

  3. HitPoint Studios: The CEO, Aaron St. John, wrote to tell me about this position in their Amherst office.

    Windows 8 XAML/C# Engineer
    HitPoint Studios is looking for an experienced engineer to work on the development of engaging front-end user interfaces for Windows Store and Windows 7 games. We are seeking someone with one or more years of experience with WPF/XAML, familiarity with Windows 8 development (Windows Store apps for Windows 8 and Windows Phone 8), a strong background in MVVM design patterns, and a good eye for UI and UX design. The position involves maintaining and improving an existing reusable code base for multiple Windows Store and Windows 7 titles with similar front end functionality but varying UI views and feature sets.

  4. Atalasoft: Atalasoft publishes developer tools for imaging and capture applications. We have a great job for a web developer that wants to spend time helping software developers get to know our company and products better. It’s in the marketing department, and you’ll be creating technical content (demos, sample code, blogs, tutorials, copy for brochures, newletters, e-learning, etc) that we can use to reach developers and get them interested in our company’s products.

Oz: Review of wizard projection technology

This is the latest in a series of limited perspective movie reviews. These reviews, inspired by a Letterman bit, look at only one narrow aspect of a movie, related to software engineering or software business.

SPOILER ALERT: These reviews assume you have seen the movie.

Here’s InceptionBreaking Dawn, Star Trek, and Alien.

Oz is set in 1905, so it doesn’t have much advanced technology. I researched the novels of Frank L. Baum, and I was surprised to learn that he wrote a novel that introduced the idea of augmented reality. Also, in the Wizard of Oz novel, the emerald city isn’t made of emerald (as it is in the original movie and this one), but instead, Dorothy and her companions are given glasses to wear that make it look as if it is. Unfortunately, since my review is limited to Oz, the movie, I can’t write up a comparison between that and Google Glasses.

Instead, I’ll concentrate on the one big use of advanced technology, the wizard’s “ghostly head” effect. If you remember the Wizard of Oz, we first see the wizard as a ghostly head appearing in smoke.

Wizard of Oz

Later, this is revealed to a projection from a complex machine operated by a man behind a curtain.

Wizard revealed

In Oz, we get a little insight into this machine. It’s implied that it was inspired by the Projection Praxinoscope.

Projection Praxinoscope

He combined the idea with Phantasmagoria, which is the projection onto smoke.

The thing is, in both of these technologies, you need to put the image on a transparent slide to shine light through. In the wizard’s case, he was able to project his live head (not a series of still images). I see no reference to this technique anywhere, but it’s a plot point that he’s being helped by The Master Tinkerer (who, in the novels, created the Tin Man), so we can assume that he could invent something.

The only thing I can think of is using a one-way mirror somehow. When I researched that, I found Pepper’s ghost:

Pepper's ghost

In this case, you are looking through a view-port (red rectangle) at an angled one-way mirror (green rectangle). The left area is out of view, and shows up in the mirror when it is lit.  You make the ghost appear and disappear by raising and dimming the light in the off-stage area as compared to the area through the mirror.

So, it’s not a projection, but I could imagine a master tinkerer and Oz (who is himself a master in prestidigitation), could figure out some way to combine these technologies (all available in the late 1800’s) to a new live smoke projection effect.

What I can’t imagine is how the older wizard is able to upgrade this to show the green, bald head instead of his own.