Let’s wrap up the discussion of project management.
How can we do project management quickly so I can spend time creating wealth for the company?
I need to know the following so that I can be sure I’m creating the most benefit:
- Is this project the best thing for me to work on?
- How much will this help the user?
- Will this make it easier to make changes in the future?
That last one is important. Once we’ve got a new change in front of users new opportunities will surface. Iteration gives more information than optimization. And if changes become easier, we can become more prolific in our changes. Prolific beats perfect.
When we make many small changes, we can check each one. Was it better for the users and our future selves? We can revert a change that wasn’t. Iteration demands that we do so. Otherwise, it becomes dead weight, dragging us down.
I’ve always interacted with Project Management as though they knew exactly what they want and I’m just implementing. As I’ve written this series, I’ve realized I don’t need to. I can push back. I can offer suggestions. I can offer anti-suggestions, which are ideas not to implement. And suggest things to remove such as failed ideas.
A few places I’ve worked have used Jira for project management. The Product Manager has an idea and enters an epic to describe it. We, the developers, break it down, estimate it, and start implementing it. That gives very little feedback to the Product Manager. Just how long we think it will take. Not whether it’s a good idea. Not if there’s a better idea. Sometimes, if I felt I had a better way, I’d point it out. But not too often.
What are the better ways? Consider an app to enter an insurance claim. A straightforward implementation would be to ask who the claim is for. On the next page ask if they have another insurance. On the next page ask what type of service it was. Another page to name and contact info of the person who provided it. Another page to ask for the price you paid and the date it happened. Another page to enter the receipt.
That pretty much describes how I currently put in my receipts. It’s painful and slow.
Speed is also a feature. Speed can mean more than one thing: speed of development, speed of process management, and speed of the final product.
The claim process above looks like it was developed quickly, but is slow for the user.
A good UX designer could make the insurance claim process less painful. For instance, a hot list of people you’ve used in the past, and remember how much they charge. Remember whether someone has another insurance and make it a side quest to add or remove it.
A good developer could make the claim process less painful. For instance, ask for the receipt up front. Most of the information is on that receipt. An ML system can read it and extract the information. Then present it back to the user to verify it’s correct.
An entrepreneur could make the claim process painless. For instance, give the user a credit card only for medical expenses. Combine it with a phone app. The user pays the provider with the card. The phone app then asks any questions it can’t figure out from the credit card transaction and explains the insurance coverage for this transaction.
The user has minimal work entering receipts, and immediate feedback on what’s covered.