That is an interesting question. Mainly because answering it raises the shades-of-grey versus black-vs-white dilemma.
is there anything wrong with building a game before I design it?
If you think of that question as a yes or no type, the answer can only be: yes, there is. If the answer can be more nuanced, then it changes. Reason: you should never build a game before some designing. But you sure can save parts of the design for later.
It means, I don't think you should see the issue at hand as a do or don't. Rather, it is something that you should think of in terms of degrees. Feature creeping maybe the very second root of all evil in what regards game development (the first, as Donald Knuth has thougth us, is that "premature optimization is the root of all evil"). However, in my experience, not thinking of any of the main features, i.e. not having at least a basic design of where you want to go with your basic mechanics, is not a good idea either.
The first main reason is that it is helpful resource-wise (including time as a resource) to have some planning to guide you trough - because reaching dead-ends all the time due to excessive try-and-error can be just as waste of resources as having to include unforeseen features.
The second main reason, game-design-wise, is coherence. Good game-design has conceptual coherence, or consistency if you want. It means, the overall game-play, the history, the implementation, even the graphics, should fit each other as smoothly as possible. It is very unlikely that a game-design will achieve something like that if main features are just found out on the go. If not for anything else, because on the go has a lot of randomness into it: the things you will step on may have very different impacts depending on when at the development process you did find them.
I don't mean saying that you shouldn't do what you said at all. I am just claiming that you have to find some balance.
For example, if I want to make a 2d platformer over the course of 6 months, can I just start making the running, jumping, shooting, etc. and add the core mechanics as I inadvertently find them? Or is this too risky of a time investment without a predetermined plan?
I would start by introducing a slight modification in your sentence. By making the running, jumping, shooting and etc you are already implementing core mechanics. What you would add on-the-go in your example are the specific game-play features.
It is not because you know the game will be a 2D platform, that running, jumping or shooting can't vary depending on the game design. Can your player run on the walls? Can your player float in the air when jumping? Even, can your player shoot while running? Does your player shoots only in a linear direction or via a parabola? These decisions can be very much game-feature dependent.
But I see your point: these mechanics often have some parts that vary very little. So, if you do some game-design and decide on basic features as much as to be somewhat sure how running, jumping, shooting, etc will work, that's a start. Then you can go for these mechanics and keep building on them.
Of course you can still later find a new feature that requires you to alter these mechanics - no matter how basic they were. But the key here is probability. The probability that this will happen too often will be smaller if you at least did some thinking on the consequences of running, shooting, jumping and etc for the basic ideas you had for the game.
Lastly, if you want to go that route, I would suggest the following. Think of it as a iterative process. You do some initial, broad-level design-thinking. You implement what seems basic and more "universal" within your game, for it to succeed. Then you do some more design-thinking, re-evaluate what you implemented and go for some more implementation.