Taking over a in life product – no documentation. What do I need?

PM's are gold or garbage, there is almost no in-between.

You want on boarding, monetization, metrics, goals attempted, successes and most importantly "what failed".

Let me say "metrics" again, what are they measuring, how, and what is and isn't working in NUMBERS. (If you don't have these god help you)

While your looking at things from a customer perspective, you should be looking at things from a storage perspective.

Where ever your data is stored, it is likely you can auto generate a schema from some sort of tool. Make these, print them out, hang them on the wall. Why dead trees? Because your going to wanna write notes on it, if you can't it's useless.

Why does storage matter? Because knowing what is there, and was there and how its laid out are going to give you massive clues as to how the system evolved! Column order in a lot of DB's is a hint at what came later. Is current critical data tacked on to the end of a table? Is there something you THINK you should be there sparsely populated because it is unused today or simply not required.

Wireframes are fast an easy, even if you do them one paper and scan them in later. I can't say enough how much having movable pieces for your work flow can help. Doing these as your learning and getting feedback on what's missing from that PM is going to give you massive insight and expose dark corners and missing thinking.

Don't panic. As someone who's done this a few times, this is typical for non pure tech companies. Go looking for people in your company that are using the product or supporting it. Typically this will be customer/client services and potentially business operations. They should be able to talk to about what doesn't work, what works well, the workarounds that have been adopted, etc. You should also talk to account managers and marketing/sales to get a feel about what clients are asking for (what features are wanted, what's missing, major flaws). Do go hunting for old specs, wireframes etc since often these are floating around but not in a central location. I've been amazed at how often these show up AFTER I've finished wrapping up a project. Often these may be owned by other departments. Make sure to ask IT to not delete the old PM's accounts but give you access to their documents and email so you can try and find old docs and email threads about decisions.

Now for the good news. With the old PM gone, you now have a blank slate to make changes, you're not beholden to their old decisions.

What do you mean by "taking over"? Are you the new Product Owner? A new coder? A one-man show doing everything? Is this part of a larger organization, or did you just pick up a codebase and you are going to try to make it into a business?

Documentation, or the lack there of has always been a pet peeve of mine. I have inherited many of these.

First step is to resist the temptation to strangle the person before you. I assume they are leaving the company as opposed to being promoted for not documenting their work.

Second step is to have great contact information about the previous owner. Ideally develop a list of all people who touched the project. This will most likely be a list of two people, you and your predecessor.

Minimal things you need to know: 1) Where are the files? 2) How do you build the project? 3) What is the typical input? 4) What is the typical output? 5) Are there any legal issue?

IMHO most projects have a collection of major parts. Start documenting those parts. Personally, I like MS One Note, but a pad of paper is better than nothing. After each major part is documented – as in a paragraph on each, start delving into each file. Create a paragraph about each.

Next I would try and document the requirements. It is critical to know what it is supposed to do. This should cover details of the goes into and goes out of. Also essential is legal issues. Everything legal you must inform management of, and have a documented reply! If there are no legal issues, you still need a confirmation email saying that. Do not put your freedom at risk, because ‘of course there are no legal issue what do you think we are building’. You should not become the patsy for someone else’s mistakes.

Bring all of this to your boss. Your boss should have some idea of the ‘Hell’ you have been inflicted with. Make sure your boss realizes: the ‘un professional’ people before you could not be bothered to document the bare minimal, but now you, ‘the professional’ has done so. Also tell them how many man hours this took.

If it looks like this is going to take more than a man week, enlist help from others to get the above done. Get your boss to agree to ‘Compensatory time off’ or ‘over time’ to get this hand over done. Since you only have a month before the person leaves. Stress to your boss, an extra man day spend this month will save a man week in the future.

Next understand how to make changes. Make some kind of needed change, and walk through the implementation. I recommend for the first one something like change of wording somewhere.

If you get help, have people document routines. 1) Purpose of routine 2) inputs 3) outputs 4) side effects.

Next document known problems.

Also obtain a list of customers who use product.

Are there test scripts? How do you run them? How do you change them.

When the month is over, analyze what you have documented. 1) Is there enough that you will not be spending most of your time saying WTF? 2) Would it be easier to re write the code? Try to resist this, as it might be easier in your mind it is often harder, and not rewriting is part of this exercise for the last month. 3) Does your boss appreciate what you have done, and how hard this is? Given the state of the project I would assume not. If your boss had any skills it would not have been left that way. Is there a bonus in your future for this? I would also consider looking for a new job. Undocumented development is a key sign for a poorly run organization.