Dear Product Manager, start from the experience, not the tech

Coming from an engineering background, I spent most of my first years as a bumbling PM championing the building of some core tech, then hope we can put an effective customer experience around it. Then I came across this quote attributed to Steve Jobs. Since then, I have consciously made an attempt to always work backwards. 

In this article, let me attempt to propose a high level sequence of steps I am currently learning to practice as the process of product design and execution.

1. Set the vision

First think through: "what's the grand outcome we'd like to achieve?". You know, if everything works out, over the very long term, what significant change or impact would we like to record and attribute to this thing we want to build. Then I question (usually in my head only ) if it's a worthy cause worth pursuing. I won't lie, I also usually attempt to figure out what I personally would like to achieve. What's in it for me as a person. Not organisation, team or anything. Me.

Also, bear in mind that Jeff Bezos quote about being stubborn on the vision but flexible on the strategy & tactics. Once this vision thing is resolved and locked in, it's time to trudge on to the next step.

2. Validate the numbers

You probably want to ensure you don't work in vain, right? So, do some market research, validate your market size and the actual addressable market based on your organisational strengths, capabilities and whatevever macro-economic realities of your market. Usually, I start from identifying who the "ideal Joe" is that will use the product. His attributes, behaviour, etc. Then I try to do some small googling around IDing how many Joes are in the market. Then try to do a business case of sorts. Excel is your friend. I have this template I use now that I have fallen in love with (though I noticed it's so complex nobody goes through it when I send it out.. lol). NOTE: reality is usually different from whatever business case you draw up, it only helps to shape your thought and motivate you to carry on (or dissuade you as the case may be).

3. Storyboard the customer experience

Note that I didn't say "user experience". Customer experience here touches every point of interaction (high level though) with the customer of this product. What sentiments we would like them to feel at any point in the interaction with the product and what they'd achieve. Study the jobs to be done framework for better understanding. I usually draw this out as a simple numbered list. Customer does x. Y happens. Then customer does y. Then z happens. That kind of thing. Focusing as little as possible on the nitty gritty details but covering the journey from start to finish. I usually refer to this as the product's "storyboard".

4. Now, draw the user experience

Okay, it's time to bring out the designer. Invest some time and possibly money here if you have to. Get someone who is experienced in this sort of thing to visually design exactly what the app/website/whatever will look and function like. There are now many apps that help to make "clickthrough prototypes". I particularly like how the designers around me use MarvelApp to string together the user experience of most things we work on. Sweat, debate, iterate this phase till everyone is comfortable.

5. Test the click through with real people

Explain the "job to be done" to a few people you ID as possible "Joes" and ask them to tap/click through what the designers came up with. Observe their discomfort and take their feedback. Then go back and argue with your designers. :D

6. Build the front end

 Take the designer's output and have your front end guy build out the full front end. If it's a mobile app, produce an actual app that covers the entire product experience. If it's a web app, HTML up the whole experience. I recently just learnt about amock.io. Good resource for pretending there's a backend when there's none. This process will lead to quite some back and forth between the designer and the front end guy. As PM, be ready to resolve a few fights. Have your pizza and beer money ready.

7. Design the data structures and APIs

Now that the thing looks real, bring the backend guy into the mix properly. He'd look through the front end implementation and determine what the data/storage structures are that would drive that visual expression. She'd also review the API requirements that the front end guy came up with. Once again, be ready to settle fights. 

8. Bonus action: start selling

Preempt the final thing and start signing up users for your product! Yes, yes, I know there's no product yet like that, but now that there's something to play with, give it to a few people and start putting together the continuous feedback into your product backlog. You'd be surprised how large your backlog will become even before you launch. I'm telling you!

Also, take this time to finalize the customer acquisition plan for post-launch. If you have a marketing team, now is the time to engage. They can see the product experience, they can see the business case, so they can start working on the comms and acquisition plan.

9. Build the backend out and integrate

Now the backend folks can do their thing. I think this is where quite a lot of the beans will come out of the woodwork. Where the tech will try to push back against the user experience. Stand your ground. Reasonably. As much as possible.

10. Develop your metrics tracker

How will you know the product is doing fine and chugging along nicely after you launch? What metrics are important? How will you know where the conversion funnel is blocking customers? Spend some deep thinking time here to come up with this reporting template you will use. Here once again Excel is your friend. Even much better if you can get the backend people to factor the logging required to achieve this reporting into their design.

11. Finalise the internal/human processes

Customer service. Approvals. Manual funnel check ins. Weekly metrics reporting. Etc. Flesh and figure this out. If you are in a large org, this can be a bloody pain. Someone somewhere will always say they were "not carried along" and drag you back to product design that counters the experience you designed. Here, if you've been a good PM, you should have a way of using influence you've built across the org to remove blockers. Pizza and beer again anyone?

12. Pilot time!!

This is where you'd continuously oscillate between despair and triumph. One moment, you feel awesome you launched, the next, something is not working. One thing to do is to see every snag as opportunity for improvement. Any assumptions you had before is up for removal. But, be not afraid, for the gods of product are with you.

13. Iterate. Iterate. Iterate.

This is where the winning happens. Try and ship something new every 2 weeks for the next 1 year. Atink. Let it be based on feedback from customers and your metrics tracker. Hopefully, you are updating all your insights into the product backlog abi? When you look back after 12 months, the product you'd be seeing wont be the same you started with. I can bet my one month salary on that. If it's still the same, your product has probably failed and didn't get any loyal users. Sorry.

One good way to ensure harmony is to see to it that the entire product team are included in all decisions. Don't get paralyzed by the indecision that comes from having many people try to agree on one thing though, just ensure they get their opinions aired, then you go ahead and let the real experts of that phase have the final decision. 

Another thing that helps is when the product team is small enough and it's truly cross-functional. From the biz dev to the QA man to the marketing guy. Even better if you can get everyone in the same room permanently. Then have frequent check-ins at least weekly. In my current team, we are experimenting with an approach where at weekly scrum, we set an objective for the week, then everyone promises what they would deliver towards that objective. Then they stake N1,000 into a pool. At the end of the month, everyone who doesn't deliver forfeits their money and it's shared by the rest who deliver. We maintain a live leaderboard that tracks history of forfeiture. Turned out to be very effective.

Once again, I'm also still learning. Writing this down is actually my own process of trying to crystalize this in my head and maybe hold myself and my goons more accountable. The process may evolve as we learn more.

Just remember, start from the customer experience.