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

https://news.ycombinator.com/item?id=21947987

by rayray07 • 7 years ago

4 10 7 years ago

news.ycombinator.com

I am taking over an existing product but there is no documentation/very poor institutional memory so I am effectively starting from scratch. What are the key things I need to learn and document to make a success of managing it in life?

I have 30 days with the existing product manager before they leave the company.

zer00eyz• 7 years ago

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.

sloaken• 7 years ago

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.

rayray074• 7 years ago

Thanks Sloaken - appreciate the length you have gone to here. Some useful suggestions but a few clarifications on my brief:

1. It's an in life product that's been in the market for a number of years, no big recent development on it from what I see.

2. I'm not responsible for the code - I work with the team that is but because it's in life don't think there is a dedicated code expert for this at the moment.

3. Boss is very aware and supportive - he laid his cards on the table when he offered me the job. They are in the same boat as they were parachuted in to takeover due to previous manager moving on.

codingdave2• 7 years ago

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?

rayray074• 7 years ago

I'm the new product owner, I don't code but manage the requirements for the team that does. It's an existing product which has been in life for many years and is part of a large organisation.

codingdave2• 7 years ago

Gotcha. In that case, I agree with some of the other comments. Sitting down and talking to the users to understand the pain points and ongoing needs is most important. Past history is not as critical because it is your job to define the future, not maintain the past.

twunde• 7 years ago

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.

mattmanser• 7 years ago

I've also had great success sitting down with a real user for an hour and getting them to go through what they do.

One particularly memorable product I did that with, I was sitting with a low level, call center type employee who was taking me through their daily job, and he pointed to a frequently needed report on screen and said "this is wrong though, I'll show you how we get the right report".

He then proceeded to fire up SQL Server Management Studio, connected to the production db and ran a script he'd been given.

All of them had read permission to the entire, extremely large, highly sensitive, db.

Because that was apparently easier for one of the devs before me than fixing the bug.

That company was bought for 9 figures a few months after that, just goes to show shoddy code and practices certainly isn't a reflection of value.

rayray074• 7 years ago

Thanks Matt, good idea - I will plan in some meet and greets with key stakeholders to watch and listen how they use/think of the product.

rayray074• 7 years ago

Thanks Twunde, this is useful. I'm trying to build a 'product manual' or similar, which will cover all the key items. Any suggestions for 'chapters'? i.e Service model, Key stakeholders.

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

Related Stories