Thoughts on the state of PM tools

I am starting to think that the problems most of us identify with project/product management tools like JIRA, Asana, and a million others are misleading.

The problem isn’t so much that we need a productive tool to manage issues and tasks. If most of what we’re doing is creating issues, assigning them, and moving them between statuses, spreadsheets do just as well as any other software minus the added complexity and ceremony. Is there then really an entire multi-billion dollar industry of project tools that simply helps us put things in cards and move them between statuses?

The reason we go to work (as a means to paying bills aside) and do what we do as engineers, designers, or product people is to build something valuable, something that makes a difference to people’s lives. I’m sure none of us would like to believe that the stories, tasks, and chores we spend hundreds of hours on don’t quite add up to something bigger, valuable, and impactful. We don’t want to learn that we were merely 50% as effective as we could be.

If we agree that building something valuable is why we go to work, the hardest problem every product/software team is confronted with is what to build. What is the magical set of things we should really be working on?

Therein lies the problem with the tools we have. They are built to manage the process of building something, not to improve the process of building the right thing.

Nearly every project management tool tries to implement one or both of two systems / abstractions – spreadsheets and Agile development. You’re given a free reign to create an endless list of tasks. When tasks moves from ToDo to Done in the time we give them, we feel good about it, and call it a successful sprint. But that, in my opinion, misses the point.

The point is not to stare at a backlog that keeps growing and pull a few things into the next sprint, or fight with a backlog of 100+ items in backlog grooming sessions,  or create a story/file a ticket based on someone asking or noticing something, or to file a bug so we feel cozy that it’s tracked, or to be a cog in a never-ending series of sprints.

We need a stronger framework to evaluate what we work on. How do we know we’re working on the right thing? How do we know the thing we worked on actually has had any impact? You can say this is not a tool problem, but a people problem. These are conversations and debates that need to happen between people.

I do think that tools can facilitate this better. The right tool can help capture the context better. This is all the more important as teams are increasingly working in a distributed and asynchronous manner.

Does everyone on your team understand the why and the what better and in full before they figure out the how? How can you tell you’re working on the right stuff?

I can’t stop thinking about this problem and what a better solution/tool for this might look like.

My initial thinking around this is that an effective tool does the following:

i) provides a structure and framework to work backwards from results that we and our customers care about. Some organizations do this with OKRs, but I might question that even in the best teams, how well do they map to the stories in JIRA?

ii) has a more structured format to capture the context, the why, the data, and the intended impact of things we are committed to working on.

iii) allows us to identify the levers that matter to our product. Consumer software businesses care about things very different enterprise/b2b software businesses. The tool we use should let us define this better.

iv) lets us visualize the needles we are moving (or that we think we are). How are we effecting impact? How do we know we’re working on the right stuff?

v) prevents us from creating stories and bugs and throwing them into a giant pool to be prioritized at some point. If you are tracking stories that have no plan for when they’ll see light of day, is there even a point to polluting your backlog with them?

vi) abandons the backlog. Backlogs are an abomination. As a PM, I hated nothing more than staring at a backlog of 100 stories. It just felt like a long list of todos and chores, and mostly just led to heartburn.

Being authentic

I am just back from watching some amazing stand-up comedians do their thing at Comedy Central in New York city.

One thing I noticed this time while watching them entertain the audience, something that hadn’t occurred to me before, is the importance of developing your own authentic style of funny. This is very apparent when you watch great comedians. No two comedians are alike. I don’t mean in the obvious sense of being different. But the best ones, they have had to take who they are as a person, and amplify that to develop a style of comedy that works best when they deliver it. They are not trying to copy another’s style.

Be it delivery, content, timing, or demeanor I would be willing to bet that who they are on stage is not that much different from who they are in life. Of course, they’ve cultivated and worked at their craft and developed a certain stage persona but if you’re not the loud, funny guy in real life, I’m not sure that you can be the loud, funny guy on stage and be good at being that guy.

You can’t have an impact on people and persuade them if you are going to put on a different skin. Leave that to the film and tv actors. It’s too transparent in real life. It doesn’t work.

I am specifically thinking about this in the context of leadership. What type of a leader are you? How do you motivate your teams? How do you deliver your message? What is your dynamic with people in your organization?

I think about what kind of a leader I am. Am I being myself? Am I being authentic? I sometimes have an out of body experience when I am talking to people in my team. In those moments, I look around the room and wonder if my words are having an impact. The times when I think I am not being effective is when I’m trying to be someone I am not, and saying things in ways that don’t align with who I am.

The best leaders are neither born, nor are they imitating other great leaders. They have strong self-awareness and understanding. Their natural traits paired with deliberate practice, effort, and development is what makes them great, in my opinion.

To influence the people and the outcomes you need, the best strategy is one part you and one part consistent and conscious practice at articulating the best in you.

Teams That Ship

Simple strategies to never lose sight of the most important weapon in a startup — shipping.

Just over a year and a half ago, my Co-founder Kate asked me if I wanted to build products for the moving industry — an industry where a majority of businesses today run on pen and paper, or outdated software. A few months prior to that, she’d started Oncue as a booking service for local movers.

When I signed on, I knew nothing about the moving industry or its pain points. While I’d built many consumer apps and products previously, I couldn’t claim to be seasoned at building SaaS products for a vertical — one where more and more business owners understood the value of having software to track sales, streamline operations, and effectively run their business.

I had to learn how a new industry functions quickly and more importantly, build a product from scratch and develop a culture of continuous and rapid shipping.

A Delicate Dance

In startups, the speed at which you ship (and therefore evolve) your product or service can make the difference between survival and death.

Take too long, and you risk learning valuable lessons sooner. Be too fast and furious, and you end up shipping things plagued by lack of quality and finesse. It feels like trying to drive with one foot on the accelerator and another on the brake.

How do you achieve speed, maintain direction, and deliver the right thing?

While I don’t claim to have all the answers, one thing we’ve done well as a team is to continually evolve the product, iterate, and add value in a consistent manner.

The journey has been rewarding and educational, but by no means smooth.

We were failing badly in those moments of customers screaming for features and feeling frustrated with our product. Moments where they say your product is too simple (it’s still simple to use, just more advanced). Deals were lost because our product wasn’t up to the mark.

When I look back to the first versions of our product, I’m mildly embarrassed. When I see our product today, I feel proud to say that I see a gamut of possibilities. It feels like we’re just getting started!

Before I dive into my learnings, two things:

  • These will resonate with you more if you’re building software products, where you have the luxury of iterating from one version to another in a matter of days. Hardware or manufacturing is outside the scope of these learnings.
  • While shipping consistently to me is like breathing, it is not crutch to compromise on the quality of your product or making sure you’re build the right product for your customers or users.

Here’s what we did right.

Build and preserve momentum like your life depends on it.

In my experience, momentum determines everything. It is highly effective as a motivator and keeping morale high. I also think present momentum is a great predictor of future progress.

At Oncue, not a week has gone by when we haven’t pushed some incremental update to the product. In a year and half, we’ve racked up more than 475 releases.

But there have been some rough phases.

We’ve spent too long on some features — the worst being almost two and a half months. In those weeks and months, it felt like time had come to a standstill. Everyone started to feel a little less excited about the feature. The product started to feel stale. While I was dealing with trying to get the feature together and keeping customers excited and morale high, juggling new requests at the same time posed its own set of challenges.

These situations aren’t always preventable, but I now try to recover from them as quickly as possible, and catch them sooner the next time around.

Whenever possible, I break up big features into atomic updates that can function on their own.

Want to track and report on open and click rates on your transactional emails?We’ll ship the tracking piece in one sprint, and reporting in the next.

Want to make file uploads and attachments available? Basic uploads and viewing attachments goes in one sprint, editing existing attachments in the next, and fancy browser for the attachments in another.

Push the product further one bit at a time, no matter how minor the change may be.

Find the right balance between polish and progress.

On a daily basis, I find myself grappling with decisions on whether to ship a feature, or continue to make it better and polish it. Launch it in its present, ready-to-use state or work at it another three weeks and make it do more? These are tough decisions, and I’d by lying if I said, I’m comfortable with all the choices I’ve made. I’ve lost count of the number of times I had to ship something knowing fully well that we could make it better.

For instance, there are more than a few screens in our product that could use some UX and UI love. Some workflows that can be twice as good. I see them in my dreams. I know it’s dirty. But they work. And customers continue to use them, and derive value from them.

The real world is unsurprisingly, messy. Engineering is hard. Things take time. You run into blind corners. There are edge cases.

The backlog of product capabilities that customers have asked for yesterday doesn’t take a break though.

I still see the warts, but I don’t lose sleep over them.

It is a vastly better approach to circle back to make something better, but after having gone to battle with it.

Dog-food your product at every step.

At Oncue, our sales reps use our product day in, day out. This creates a feedback loop that has been incredibly valuable. The feedback-fix-improvement cycle on many product capabilities is therefore much quicker.

This may not always be possible. If you’re solving problems for a vertical, ideally you have strong domain expertise. If you don’t, you’re going to have to construct channels that provide you with early and rapid feedback.

Perhaps cultivate a group of alpha testers amongst your customers?

Create a fictitious company and ask employees to use your SaaS app?

Building in the dark or based on gut/assumptions is an invitation for nasty surprises, often much too late.

Whatever it takes, find ways to create extremely quick customer interview/iterate/feedback cycles.

When possible, being your own customer is invaluable.

Avoid rabbit-holes like the plague.

This one is my favorite. Mostly because it might be the most common sin.

It’s tempting to design features that look incredible in Sketch, but will take your engineering team twice as long to build (and are most likely not optimized for user experience anyway).

It’s tempting to prematurely over-engineer your technical infrastructure.

It’s tempting to spend days automating something when a manual solution will do just fine for some more time.

It’s tempting to spend too long debating tools and processes and code and design patterns but not pick something that works well and move on.

I’ve committed each of these errors at one point or another.

But they are all rabbit holes. They slow the march. They suck more time than is necessary, and distract from what is truly important.

As product owners who care about every last detail, it’s tempting to want to fix a nagging issue or clean up that Settings interface that looks ugly. Who doesn’t want to clean house? Stop. Question if it will have a material impact on the customer’s decision to buy the product, or continue to engage with it. The answer may likely be no.

Be ruthless in doing things that need to be done, not the things you want to do.

Conclusion

As an early stage company, we don’t have the luxury of spending long cycles on things that will not lead to answers quickly, or make our customers more successful.

I’m in no way advocating for shortcuts, cutting corners, or building a poor product. But I believe it is critical to foster a team ethos that understands the right trade-offs and is comfortable with making those choices.

There’s only one priority — solve the right problem for your customer, and do it better and faster than others.

Focus on it.

Customers have too many choices. Let’s make them fall in love with our work by continually delighting them.

When the best insights in the room may not be yours.

While watching the fantastic “Becoming Warren Buffet” documentary, I realized something, which I have to admit had eluded me or may be I was too afraid to admit.

In his early investing days, Buffet was mostly into “cigar butt” stocks – cheap stocks of poorly performing companies that had “one last puff” left in them. He’d buy them and turn them into a profit, and he made an enormous amount of money (for its time) doing just that.

It was Charlie Munger who turned him to a more value-based investing philosophy – buying stocks of wonderful companies at fair prices rather than fair companies at wonderful prices. This arguably formed the foundation of the two greatest investor(s) of our times. However, if Buffet had not been open and welcoming to a new idea and been defensive about his way or fretted about he not realizing it, he may have possibly missed the greatest opportunity of his life.

If you’re an even reasonably smart person who prides on thinking deeply and originally, at some point you’re going to come into this realization that the best ideas or insights in the room may not and will not be yours and you will have to be very gracious and rational about it if you are to succeed. You can either get worked up about it and beat yourself up over it, or you can accept it and be rational about it and not care so much about who gets the credit for the idea.

Charlie Munger speaks..

If you’re glued together, honorable, get up every morning and keep doing it, keep learning everyday, and you’re willing to go in for a lot of deferred gratification in your life you’re gonna succeed. It may not be as much as you want but you’re going to succeed. The main thing is to keep in there. Get rid of your stupidities as fast as you can and avoid the bad people as much as you can and you’ll do reasonably well.

https://www.youtube.com/watch?v=BLctqhNClqY @ 59:00

What to do about the competition?

A few days ago, I panicked when I saw a competitor do something we had planned. I couldn’t shake off that moment of desperation when I realized we won’t be first to market with this.

A few days have gone by and I’m fairly settled and sure about our position now, and I worry less about the competition. But sitting on this feeling for a while made me realize something.

In tennis, there is the notion of unforced errors, which are mistakes _you make_, they’re of your own doing, not necessarily because the opponent is better. One could apply this notion to companies too.

There is nothing you can do about competition. It will always be there, and some of it might be better than you.

What is under your control though, is how you play. Reduce the number of unforced errors you make. By minimizing the stupid things you do and mistakes of bad execution, one could likely go much further and win more than worrying about one-upping the competition every time.

While this doesn’t obviate the basic requirement that your product is good, it frees you up from pointless worries.