For more human apps—product management vs. project management.

As the delivery manager for Skuid’s professional services, I servant-lead a team of talented solutioneers in delivering world-class expertise to our customers as they continue their journeys with Skuid.

I’ve been reflecting on where I see organizations become wildly successful, and where I see organizations struggle with creating, launching,  and managing business apps. For me, a pattern emerges. I’m not an expert—and 18 months ago I wasn’t thinking this way. I’ve learned from others, and experiences continue to change my thinking.

Why aren’t people using my app?

When it comes to user adoption and loyalty, you can have the winning technology (I work at Skuid because I believe it is winning tech).

You can have winning app builders (I’m humbled to serve some of the winningest out there).

You can have a ninja assassin project manager (I’d never purport to have been one, but I know what it takes for sure—super hard job).

You can have all that, and users still won’t adopt that app—even under threats or bribes. With no loyalty fostered – the users have moved on, and maybe the sponsors too.

Why?

In my experience, there’s usually a key factor: how you’re managing the development, delivery, and iteration of your app. I define the struggle as product management versus project management, and what businesses are prepared and willing to do for the end user.

Two mindsets, contrasted.

Here’s a quick list of differences between project management and product management:

Projects are usually temporary initiatives that are opened and closed—but we don’t expect it to work exactly right the first time. And that’s why we allow for two days of testing, and three days of developer fixes. Then, it has to work perfectly—because we won’t have the budget to revisit it for 2-5 years. And the people have already been moved on to the next project.

Products are permanent creations with an ongoing journey and expected growth. Iteration is never over. The app is never complete. We keep the people who built the product in place to closely observe, learn from, change, and redeploy new or improved features based on thoughtful design.

Projects tend to have matrix teams of people fulfilling temporary roles to execute the project scope and deliverables on time, under budget. Get in, finish the project, and get out. And watch out for people or vendors who want to get in and never finish, right?

Projects imply one-time limited budget, time, resource, and people investments—and anything after that is usually seen a bad thing to stop as soon as possible.

Products tend to have a dedicated team of purpose-defined roles owning the responsibility to see that product get in the hands of users, be highly adopted, and continuously become more valuable to those users. Get in, and stay in.

Products imply initial and ongoing budget, time, resource, and people investments—and those are seen as good things to keep going as long as possible.

Projects have schedules and deadlines. Products have roadmaps and releases.

Project management tends to focus on managing everything up to the point of giving the user something. That means the project adheres to stricter constraints with more time focused on the past, and less time spent thinking about what happens next after the user has the product.

Product management tends to focus on planning for everything after the product is delivered to the user – but this doesn’t mean the past or present are ignored. Rather, a product team places more focus on how to design an ongoing product management cycle that nurtures user happiness and loyalty.

I could go on—and this isn’t about playing semantics with terminology. You could take either and probably build a case. This is my personal journey in observing how people tend to think about projects vs. products. Goodness can, and still does, happen in project management. Certainly, there’s plenty that can go wrong with product management too.

But from my perspective, I’d rather be creating business apps with a product team instead of a project team.

Here’s why: both teams can claim to be all about the end user and business outcomes. But only one team is positioned to actually be there, intact, to witness and do something about the end user and business outcomes 12 months after launch.

So, how are you managing your business apps? Is your app a project, or a product?

Ready to see the kinds of apps you can build with Skuid? Get a Skuid demo today, or learn more about our Professional Services here.

Delivery Manager, Eastern Region | Professional Services

I love people, coffee, dreaming big, and helping teams design and build world-class enterprise applications.