Product Development Is Not My Thing

flowchart of agile software product development
It’s been about eight months since I started working for a software product company. Prior to that, I’d spent a lot of time writing software for various audiences – but always for internal use. At my current gig, I’m not working directly in software product development – my role is quality assurance and testing.

I’m not directly influencing the software product output. I am influencing primarily the software development process which causes that output – by finding bugs, finding process problems, and recommending improvements. It’s an internal support service role.

Probably my most natural role in technology is in the areas of support and service. That can mean many things, and in the case of my current job role it means I provide a service to help ensure high quality in the product that the company sells. I’m not sure if I would want to work directly on the product side – even though that’s the revenue generator, it is also the area where the work can get bogged down in a lot of details that don’t necessarily lead to creative solutions to technology problems.

True, in an ideal world product developers would always be primarily focused on innovating and providing the most creative solutions, but in the end the constraints of working within a product framework mean there are a lot of limits on what can be done. Every decision must keep in mind not just the problem at hand, but also the generalized problem that the anticipated product audience has. There is naturally a constant struggle to retain innovation.

When you work directly in service or support, you also have these sorts of constraints but the decisions and actions you take have a little more wiggle room because they aren’t getting baked into the product. There’s a little more chance to be flexible, find new and promising solutions, and move freely.

But of course that only matters if you find ways to take advantage of that flexibility.