Oh there are so many things, and this is such a good question to be asking.
To keep it short, the number one thing I would say is naming conventions. Decide on your naming conventions and get them on LOCK - make sure they're followed consistently and don't be lax on it. There's tons of stuff in community about naming convention structure (defs including a few rants from me), but this would seriously be my number one.
That and be very very selective about custom fields. Don't go creating them left right and centre 
Yeah - what Pamela said. Support are the only ones that can delete fields once they've been used, and it just gets INCREDIBLY messy as an instance scales and ages if you're creating custom fields left right and centre for one-off needs. You want to be only creating custom fields for things you ABSOLUTELY need, and you want to be incredibly clear on your naming conventions for them and very well thought out about how they're used (and ideally document that somewhere).
Paul Wilson shared a brilliant tip with me earlier this year which I would implement from scratch if I had a clean instance, where you create a number of fields of each type with generic "Custom String Field 01" names, and then users can check those fields out for temporary use, wipe them when they're done, and return them like library books. I do this now and it's proven really brilliant - just make sure you have a clear process for "checking out" fields
But also little things like subscription management fields - if you're doing any custom ones here - it should be immediately obvious from the naming convention whether a true = yes or true = no. I've had scenarios where I've inherited instances and it's not clear either from the naming convention or from historical use of the field whether it's meant to be a true for opt in or a true for opt out... don't do that, it's challenging to unpick!
I completely agree on naming conventions for a couple of reasons.
- They enable you to develop cleaner reporting and find your programs and assets more easily.
- When you create your lead management process, having naming conventions around your forms will be critical to isolate only those forms that fast track people as MQLs.
- If you have multiple products/divisions in your org, this is the way to differentiate your programs for scoring and qualification purposes.
Other things I would mention:
- Lock down your program templates (the campaign library) and train your marketing users to work from pre-built program templates vs. customizing their Marketo programs. Consistency is your friend.
- Limit the number of forms you use, use a naming convention, and be sure that all of them live in the Design Studio. Forms in Marketing Activities can become a huge headache.
- Make sure that the Marketo Form ID is included in your form naming convention. If you have any Marketo forms embedded in external websites, this will be a big timesaver.
- Embed all of your marketing activities into a nested folder structure and use Folder Tokens to standardize company-level metadata used in all of your programs (copyright year, address, company name, etc.), and then bake these tokens into your email and landing page templates. If you need to make changes to anything that is org-wide, this will save you a ton of time.
There are lots of great ideas on this thread. I hope I was able to also help. Good luck with your implementation
.png)