If ever there was a bad smell for lazily designed objects it would come from private methods. Every private method introduced should be a red flag, triggering a second glance at how responsibilities are being divided between objects.
Good objects provide a trustable, well-balanced interface to a simple implementation of some useful metaphor. Object-oriented programming is all of the activities we employ to make good objects. Unfortunately, many people mistakenly apply these activities to only a narrow aspect of programs, what is called the domain model, leaving the other domains that converge on the program to rot.
Often the mistake is in assuming that the business domain is the only domain that needs to be modeled. Instead, it should to be understood that many domains come together to make a program possible. Rotten software, like everything else that rots, is found hiding in the neglected, intentionally overlooked, private corners of things (in this case objects.) Each private bit of behavior is an opportunity for a new domain of good objects to take over. Freeing up your objects to do only those things relevant to their specific domains.
If you find yourself making private methods ask yourself why and see if there is a better design tool available. If you don't think one exists, consult someone who might provide a different perspective. Either way, seek out some way of solving your problem that doesn't involve hiding behavior. I worryingly quote the NSA, "If you have nothing to hide, you have nothing to fear." If you have something to fear, you probably have some poor design.